diff --git a/README.md b/README.md
index 655fc5088..abcbf1efc 100644
--- a/README.md
+++ b/README.md
@@ -311,7 +311,7 @@ The packages have are installed in the _package.json_ and imported into the proj
You simply need to add your equations to your Markdown file, keeping all the elements between opening an closing tags _$_.
$$
-\omega=\cfrac{v_{r}-v_{l}}{w}
+\omega=\cfrac{v_{r}-v_{l}}{W}
$$
You can test equation syntax using [this tool](https://katex.org/) from KaTex.
diff --git a/components/introduction_husky_a300.mdx b/components/introduction_husky_a300.mdx
new file mode 100644
index 000000000..3bf649ba3
--- /dev/null
+++ b/components/introduction_husky_a300.mdx
@@ -0,0 +1,8 @@
+
+
+
+
+---
diff --git a/components/maintenance/bill_of_materials_note.mdx b/components/maintenance/bill_of_materials_note.mdx
index 2c4245186..8389f9103 100644
--- a/components/maintenance/bill_of_materials_note.mdx
+++ b/components/maintenance/bill_of_materials_note.mdx
@@ -2,6 +2,6 @@
This does not cover the full bill-of-materials for your robot.
These items are things we consider critical, so you may want to keep spares on hand.
-You can get any replacement part by contacting , including parts not listed here.
+You can get any replacement part by contacting \, including parts not listed here.
:::
diff --git a/components/maintenance/firmware_update_puma.mdx b/components/maintenance/firmware_update_puma.mdx
index 18f3ce7a9..43608be34 100644
--- a/components/maintenance/firmware_update_puma.mdx
+++ b/components/maintenance/firmware_update_puma.mdx
@@ -1,4 +1,6 @@
-Click to expand
+
+ Click to expand
+
#### 1. Tools required:
@@ -169,7 +171,7 @@ You will see the following message when the firmware installation is complete:
```
Application : motor_controller_firmware_husky_001.bin
Program Address: 0x0
- COM Port: /dev/ttyUSB0
+ COM Port: /dev/ttyUSB0
Baud Rate: 115200
Erasing Flash:
Remaining Bytes: 00000000
@@ -193,4 +195,5 @@ Once it has restarted, use a joystick to drive it around.
The robot's dynamics may be very different than what you are familiar with.
The new firmware will change how the motor's react to `/cmd_vel` messages, so you should test in a controlled setting.
-
+
+
diff --git a/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx b/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx
index 5ff1684a5..a8f7319db 100644
--- a/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx
+++ b/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx
@@ -1,4 +1,6 @@
-Click to expand
+
+ Click to expand
+
#### 1. Tools required:
@@ -253,4 +255,5 @@ You can drop the pressure to as low as 69 kPa (10 psi).
These anomalies can cause the Husky to not drive straight, and affect your autonomy program's performance.
-
+
+
diff --git a/components/support.mdx b/components/support.mdx
index 8aa469993..25813417e 100644
--- a/components/support.mdx
+++ b/components/support.mdx
@@ -1,8 +1,9 @@
Clearpath is committed to your success.
-Please get in touch with us and we will do our best to get you rolling again quickly: .
+Please get in touch with us and we will do our best to get you rolling again quickly: \.
-To get in touch with a salesperson regarding Clearpath Robotics products, please email .
+To get in touch with a salesperson regarding Clearpath Robotics products, please email \.
-If you have an issue that is specifically about ROS and is something which may be of interest to the broader community, consider asking it on .
+If you have an issue that is specifically about ROS and is something which may be of interest to the broader community,
+consider asking it on [Robotics Stack Exchange](https://robotics.stackexchange.com).
If you do not get a satisfactory response, please ping us and include a link to your question as posted there.
-If appropriate, we will answer in the ROS Answers context for the benefit of the community.
+If appropriate, we will answer on Robotics Stack Exchange for the benefit of the community.
diff --git a/components/support_introduction.mdx b/components/support_introduction.mdx
index 8b3a19730..8dae5ac90 100644
--- a/components/support_introduction.mdx
+++ b/components/support_introduction.mdx
@@ -1,6 +1,6 @@
Robots are complex.
Common issues are listed below.
-Contact our support team at if the issue persists.
+Contact our support team at \ if the issue persists.
:::info
diff --git a/components/support_outdoornav.mdx b/components/support_outdoornav.mdx
index b0dfa4be0..f96c67cd2 100644
--- a/components/support_outdoornav.mdx
+++ b/components/support_outdoornav.mdx
@@ -1,5 +1,5 @@
Clearpath is committed to your success.
-Please get in touch with us and we will do our best to get you rolling again quickly: .
+Please get in touch with us and we will do our best to get you rolling again quickly: \.
If possible, include as much of the following information as possible in your OutdoorNav support request:
- OutdoorNav software version
@@ -14,8 +14,8 @@ If possible, include as much of the following information as possible in your Ou
command on the computer with OutdoorNav installed:
`cd ~/cpr_outdoornav_launch && docker compose --profile=outdoornav logs > $(date +"%Y_%m_%d_%I_%M_%p").txt`
-To get in touch with a salesperson regarding Clearpath Robotics products, please email .
+To get in touch with a salesperson regarding Clearpath Robotics products, please email \.
-If you have an issue that is specifically about ROS and is something which may be of interest to the broader community, consider asking it on .
+If you have an issue that is specifically about ROS and is something which may be of interest to the broader community, consider asking it on https://robotics.stackexchange.com.
If you do not get a satisfactory response, please ping us and include a link to your question as posted there.
If appropriate, we will answer in the ROS Answers context for the benefit of the community.
diff --git a/docs/components/_clearpath_firmware.mdx b/docs/components/_clearpath_firmware.mdx
new file mode 100644
index 000000000..9037e4233
--- /dev/null
+++ b/docs/components/_clearpath_firmware.mdx
@@ -0,0 +1,361 @@
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+:::caution
+
+Before flashing firmware, place your robot up on blocks or disengage the drivetrain. Firmware loading does not usually result in unintended motion, but it is safest when off the ground.
+
+:::
+
+
+
+
+
+
+ #### 1. Download the Clearpath Firmware package from the Clearpath package server
+
+ On the robot computer, run the following commands:
+
+ ```
+ sudo apt-get update
+ sudo apt-get install ros-humble-clearpath-firmware
+ ```
+
+ #### 2. Prepare the Robot
+
+:::note
+
+ The J100 MCU does not have an ethernet interface, and therefore cannot be flashed using the eternet bootloader. You must follow the subsequent steps to flash the J100 MCU over mini-USB.
+
+:::
+
+ The J100 MCU is mounted to the rear inside wall of the robot. To access it, open the lid, keeping the computer
+ tray secured to the underside of the lid.
+
+
+
+
+ J100 MCU
+
+
+
+
+
+ J100 MCU labels
+
+
+ The M_RST button, used to reset the MCU.
+
+
+ The PWR_MODE switch. Left is NORM or normal mode, right is ALT or bootloader mode. This is used for flashing the firmware.
+
+
+ The mini-USB port used for transmitting data. This should be connected to J100's computer for both normal operation and firmware flashing.
+
+
+
+
+ **Place the J100 MCU into bootloader mode**
+
+ Open the lid of the robot to expose the MCU and make sure the mini-USB cable is connected to the robot computer.
+ Switch the PWR_MODE switch from NORM to ALT. If the robot is on, press the M_RST button. Otherwise, turn the robot on with the power button.
+
+
+
+
+
+ #### 1. Download the Clearpath Firmware package from the Clearpath package server
+
+ On an external computer, run the following commands:
+
+ ```
+ sudo apt-get update
+ sudo apt-get install ros-humble-clearpath-firmware
+ ```
+
+ #### 2. Prepare the Robot
+
+:::note
+
+ Platforms with an Ethernet connection to the MCU have the option of flashing over USB or Ethernet.
+ If you are updating to ROS 2 Humble for the first time, you must use USB. If you are updating ROS 2 Humble firmware
+ to a newer version, using Ethernet is recommended. Skip this step if flashing over Ethernet.
+
+:::
+
+ The W200 MCU is located on the underside of the metal frame over the top of the computer.
+
+
+
+
+ W200 MCU
+
+
+
+
+
+ W200 MCU labels
+
+
+ The RST button, used to reset the MCU.
+
+
+ The BT0 button, used to enter the USB bootloader mode.
+
+
+
+
+ **Place the W200 MCU into bootloader mode**
+
+ While pressing BT0 on the MCU, connect the external computer to Warthog's MCU using a USB cable.
+
+
+
+
+
+ #### 1. Download the Clearpath Firmware package from the Clearpath package server
+
+ On the robot computer, run the following commands:
+
+ ```
+ sudo apt-get update
+ sudo apt-get install ros-humble-clearpath-firmware
+ ```
+
+ #### 2. Prepare the Robot
+
+:::note
+
+ Platforms with an Ethernet connection to the MCU have the option of flashing over USB or Ethernet.
+ If you are updating to ROS 2 Humble for the first time, you must use USB. If you are updating ROS 2 Humble firmware
+ to a newer version, using Ethernet is recommended. Skip this step if flashing over Ethernet.
+
+:::
+
+ Place the R100 Ridgeback up on blocks. Firmware loading does not usually result in unintended motion, but it's safest when off the ground.
+
+ Remove the side panels to access the robot computer and MCU.
+
+ Connect the MCU to the R100 Ridgeback's onboard computer using a mini-USB cable connected to the port shown below:
+
+
+
+
+ R100 MCU mini-USB port
+
+
+
+ In the middle of the MCU, there is a two-position switch labelled `PWR_MODE`. Move the switch from the default `NORM` position to the `AUX` position.
+
+ Press the `M_RST` to restart the MCU. Now, the MCU is in boot-loader mode, ready to receive new firmware.
+
+
+
+
+ R100 MCU mode switch and reset button
+
+
+
+:::note
+
+The Ridgeback's MCU is normally rotated 90 degrees when it is installed in the robot; the `NORM` position is typically towards the top of the robot's chassis and the `AUX` position is normally towards the bottom.
+
+:::
+
+
+
+
+
+ #### 1. Download the Clearpath Firmware package from the Clearpath package server
+
+ On the robot computer, run the following commands:
+
+ ```
+ sudo apt-get update
+ sudo apt-get install ros-humble-clearpath-firmware
+ ```
+
+ #### 2. Prepare the Robot
+
+:::note
+
+ Platforms with an Ethernet connection to the MCU have the option of flashing over USB or Ethernet.
+ If you are updating to ROS 2 Humble for the first time, you must use USB. If you are updating ROS 2 Humble firmware
+ to a newer version, using Ethernet is recommended. Skip this step if flashing over Ethernet.
+
+:::
+
+ The DX100 MCU is mounted near the HMI panel towards the rear of the robot. To access it, remove the antennas and the center channel panel.
+
+ Connect the MCU to the onboard computer using a mini-USB cable connected to the port as shown below:
+
+
+
+
+ DX100 MCU mini-USB port
+
+
+
+ As is shown in the image above, set the `PWR_MODE` switch to the `ALT` position.
+
+ Press the `M_RST` or restart the robot using the HMI panel. Now, the MCU is in boot-loader mode, ready to receive new firmware.
+
+
+
+
+
+ #### 1. Download the Clearpath Firmware package from the Clearpath package server
+
+ On the robot computer, run the following commands:
+
+ ```
+ sudo apt-get update
+ sudo apt-get install ros-humble-clearpath-firmware
+ ```
+
+ #### 2. Prepare the Robot
+
+:::note
+
+ Platforms with an Ethernet connection to the MCU have the option of flashing over USB or Ethernet.
+ If you are updating to ROS 2 Humble for the first time, you must use USB. If you are updating ROS 2 Humble firmware
+ to a newer version, using Ethernet is recommended. Skip this step if flashing over Ethernet.
+
+:::
+
+ The DX150 MCU is mounted near the HMI panel towards the rear of the robot. To access it, remove the antennas and the center channel panel.
+
+ Connect the MCU to the onboard computer using a mini-USB cable connected to the port as shown below:
+
+
+
+
+ DX150 MCU mini-USB port
+
+
+
+ As is shown in the image above, set the `PWR_MODE` switch to the `ALT` position.
+
+ Press the `M_RST` or restart the robot using the HMI panel. Now, the MCU is in boot-loader mode, ready to receive new firmware.
+
+
+
+
+
+#### 3. Flash the firmware
+
+Run the Clearpath firmware flash tool:
+
+```
+source /opt/ros/humble/setup.bash
+ros2 run clearpath_firmware flash
+```
+
+Select your platform, then select which method of flashing you would like to use.
+
+:::caution
+
+Do not turn the robot off or unplug the cable while flashing firmware. If an error occurs while
+flashing, you can attempt to flash again over USB.
+
+:::
+
+#### 4. Place the robot back into normal operating mode
+
+:::note
+
+If you flashed over Ethernet, skip this step.
+
+:::
+
+
+
+
+ Switch the PWR_MODE switch from ALT back to NORM. The robot will turn off.
+ Power it back on with the power button.
+
+
+
+
+
+ Press the RST button. The MCU should enter regular operation.
+
+
+
+
+
+ Switch the PWR_MODE switch from ALT back to NORM. The robot will turn off.
+ Power it back on with the power button.
+
+
+
+
+
+
+ Switch the PWR_MODE switch from ALT back to NORM. The robot will turn off.
+ Power it back on with the power button.
+
+
+
+
+
+
+ Switch the PWR_MODE switch from ALT back to NORM. The robot will turn off.
+ Power it back on with the power button.
+
+
+
+
diff --git a/docs/components/_jackal_firmware.mdx b/docs/components/_jackal_firmware.mdx
new file mode 100644
index 000000000..5ba4cc90d
--- /dev/null
+++ b/docs/components/_jackal_firmware.mdx
@@ -0,0 +1,61 @@
+:::note
+
+Jackal's MCU is mounted to the rear inside wall of the robot. To access it, open the lid, keeping the computer
+tray secured to the underside of the lid.
+
+
+
+
+ Jackal's MCU
+
+
+
+1. The `M_RST` button, used to reset the MCU.
+2. The MCU mode switch. Left is `NORM` or normal mode, right is `ALT` used for flashing the firmware.
+3. The mini-USB port used for transmitting data. This should be connected to Jackal's computer for both normal operation and firmware flashing.
+
+:::
+
+Jackal firmware can be flashed from the Jackal's computer.
+
+**1. Download the Jackal Firmware package from the Clearpath package server**
+
+```
+sudo apt-get update
+sudo apt-get install ros-humble-jackal-firmware
+```
+
+**2. Prepare the Robot**
+Place Jackal up on blocks. Firmware loading does not usually result in unintended motion, but it's safest when
+off the ground.
+Open the lid of the robot to expose the MCU and connect the mini-USB cable (`3` in the image above).
+
+**3. Place the Jackal MCU into bootloader mode**
+
+Switch the _PWR_MODE_ switch (`2` in the image above) from _NORM_ to _ALT_. If the robot is on, press the _M_RST_ button. Otherwise, turn the
+robot on with the power button.
+
+**4. Flash the firmware**
+
+```
+jackal_firmware_flash.sh
+```
+
+Flashing progress will be indicated by the flash script. Wait for the firmware to finish flashing.
+
+:::caution
+
+Do not turn the robot off or unplug the mini-USB cable while flashing firmware. If an error occurs while
+flashing, you can attempt to run `jackal_firmware_flash.sh` again.
+
+:::
+
+**4. Place the Jackal MCU into normal mode**
+
+Once the firmware has been flashed, place the Jackal MCU back into normal mode by switching the PWR_MODE switch from _ALT_ to _NORM_.
+The robot will power off. Turn the robot back on by pressing the power button.
+
+Jackal will now be using the new firmware you installed.
\ No newline at end of file
diff --git a/docs/components/_tutorials_link.mdx b/docs/components/_tutorials_link.mdx
new file mode 100644
index 000000000..b38a374ad
--- /dev/null
+++ b/docs/components/_tutorials_link.mdx
@@ -0,0 +1,30 @@
+:::note
+
+These tutorials assume that you are comfortable working with [ROS](https://docs.ros.org/). We recommend starting with
+[ROS 2 tutorials](https://docs.ros.org/en/humble/Tutorials.html) if you are not familiar with ROS already.
+
+:::
+
+## Topics
+
+You can view all topics that are active using `ros2 topic list`.
+
+For a general list of topics and descriptions see the [Clearpath API](../ros/api/platform_api.mdx)
+
+## Software Setup
+
+- [Robot Software](../ros/installation/robot.mdx)
+- [Offboard Computer](../ros/installation/offboard_pc.mdx)
+- [PS4 Joystick Controller (if applicable)](../ros/installation/controller.mdx)
+
+## Using your Robot
+
+The following tutorials are recommended to get to know your robot:
+
+- [Driving your Robot](../ros/tutorials/driving.mdx)
+- [Simulating your Robot](../ros/tutorials/simulator/overview.mdx)
+- [Navigating](../ros/tutorials/navigation_demos/overview.mdx)
+
+## Advanced Topics
+
+- [Configuring Network Bridge](../ros/networking/computer_setup.mdx)
diff --git a/docs/components/networking/_computer_networking_setup_install.mdx b/docs/components/networking/_computer_networking_setup_install.mdx
new file mode 100644
index 000000000..6eea619e6
--- /dev/null
+++ b/docs/components/networking/_computer_networking_setup_install.mdx
@@ -0,0 +1,15 @@
+The `clearpath_computer_setup` package offers a terminal menu tool for configuring a robot computer.
+The main feature of this tool is the ability to generate `netplan` configurations. The `clearpath_computer_setup`
+package is available on the [Clearpath package server](../../ros/installation/robot.mdx#clearpath-package-server).
+
+It should be installed on the robot's computer:
+
+```
+sudo apt install python3-clearpath-computer-setup
+```
+
+To run the tool, call:
+
+```
+sudo clearpath-computer-setup
+```
\ No newline at end of file
diff --git a/docs/components/networking/_ros2_networking_overview.mdx b/docs/components/networking/_ros2_networking_overview.mdx
new file mode 100644
index 000000000..8a542586c
--- /dev/null
+++ b/docs/components/networking/_ros2_networking_overview.mdx
@@ -0,0 +1,14 @@
+ROS 2 networking uses an abstracted middleware referred to as the "RMW Implementation". The Clearpath robot packages support
+eProsima Fast DDS as the middleware implementation. This middleware has two supported options for ROS 2 node discovery, Simple
+Discovery and Discovery Server. Each of these discovery mechanisms has their own use case:
+
+**Simple Discovery**
+- Default, does not require manual setup
+- Generally operates on the basis that any ROS 2 devices on the network should be discoverable and connect automatically
+- Requires multicasting on the network (may be restricted on school or corporate networks)
+- Good for simple systems (small number of robots on a dedicated local network)
+
+**Discovery Server**
+- Requires manual configuration in the robot.yaml
+- Generally operates on the basis that ROS 2 networks should be controlled and can only discover other devices as directed
+- Does not require multicasting (more likely to work on school or corporate networks)
\ No newline at end of file
diff --git a/docs/components/networking/_standard_clearpath_bridge_setup.mdx b/docs/components/networking/_standard_clearpath_bridge_setup.mdx
new file mode 100644
index 000000000..a760e3bff
--- /dev/null
+++ b/docs/components/networking/_standard_clearpath_bridge_setup.mdx
@@ -0,0 +1,13 @@
+The default networking configuration for a robot's computer is to bridge all Ethernet interfaces and assign the computer
+the IP address `192.168.131.1`. See [Network IP Addresses](../../ros/networking/network_ip_addresses.mdx) for a detailed list of IP ranges.
+
+To configure the default bridge:
+1. Run `sudo clearpath-computer-setup`
+2. Navigate to **Netplan Setup** -> **Pre-set Configurations**.
+3. Select **Standard Clearpath Bridge** and generate the configuration by following the instructions.
+4. Return to the **Netplan Setup** menu and select **Apply Configuration Changes**.
+
+This will create a `/etc/netplan/50-clearpath-standard.yaml` file and apply the changes to `netplan`.
+
+Once the network settings have been applied, call `ip a` to check that the network bridge has been created, and
+that the computer has been assigned the `192.168.131.1` IP address.
\ No newline at end of file
diff --git a/docs/components/yaml/attachments/a200/bumper.mdx b/docs/components/yaml/attachments/a200/bumper.mdx
new file mode 100644
index 000000000..4637697f7
--- /dev/null
+++ b/docs/components/yaml/attachments/a200/bumper.mdx
@@ -0,0 +1,36 @@
+
+
+Attach accessories to the sensor arch mount by setting the accessory's `parent` parameter to `arch_sensor_mount`.
diff --git a/docs/components/yaml/attachments/a200/sensor_arch_510.mdx b/docs/components/yaml/attachments/a200/sensor_arch_510.mdx
new file mode 100644
index 000000000..18fea5c14
--- /dev/null
+++ b/docs/components/yaml/attachments/a200/sensor_arch_510.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the sensor arch mount by setting the accessory's `parent` parameter to `arch_sensor_mount`.
diff --git a/docs/components/yaml/attachments/a200/top_plate_default.mdx b/docs/components/yaml/attachments/a200/top_plate_default.mdx
new file mode 100644
index 000000000..4696e45ab
--- /dev/null
+++ b/docs/components/yaml/attachments/a200/top_plate_default.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the top plate mounts by setting the accessory's `parent` parameter to either `top_plate_rear_mount`, `top_plate_default_mount`, or `top_plate_front_mount`. The mounts are displayed as axes in the image above.
diff --git a/docs/components/yaml/attachments/a200/top_plate_large.mdx b/docs/components/yaml/attachments/a200/top_plate_large.mdx
new file mode 100644
index 000000000..cdc2ee1b2
--- /dev/null
+++ b/docs/components/yaml/attachments/a200/top_plate_large.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the top plate mounts by setting the accessory's `parent` parameter to either `top_plate_rear_mount`, `top_plate_default_mount`, or `top_plate_front_mount`. The mounts are displayed as axes in the image above.
diff --git a/docs/components/yaml/attachments/a200/top_plate_pacs.mdx b/docs/components/yaml/attachments/a200/top_plate_pacs.mdx
new file mode 100644
index 000000000..d89c1a75a
--- /dev/null
+++ b/docs/components/yaml/attachments/a200/top_plate_pacs.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the top plate mounts by setting the accessory's `parent` parameter to one of the grid mounting locations displayed above. The grid mounting locations span from `top_plate_mount_a1` to `top_plate_mount_g8`, where the front left-most location is the `a1` mount and the bottom right-most location is the `g8` mount. The letters correspond to the columns and the number to the rows.
diff --git a/docs/components/yaml/attachments/dx1X0/img/top_plate_dd100.png b/docs/components/yaml/attachments/dx1X0/img/top_plate_dd100.png
new file mode 100644
index 000000000..715880ade
Binary files /dev/null and b/docs/components/yaml/attachments/dx1X0/img/top_plate_dd100.png differ
diff --git a/docs/components/yaml/attachments/dx1X0/img/top_plate_dd150.png b/docs/components/yaml/attachments/dx1X0/img/top_plate_dd150.png
new file mode 100644
index 000000000..ce87d2ee3
Binary files /dev/null and b/docs/components/yaml/attachments/dx1X0/img/top_plate_dd150.png differ
diff --git a/docs/components/yaml/attachments/dx1X0/img/top_plate_do1X0.png b/docs/components/yaml/attachments/dx1X0/img/top_plate_do1X0.png
new file mode 100644
index 000000000..6d736d416
Binary files /dev/null and b/docs/components/yaml/attachments/dx1X0/img/top_plate_do1X0.png differ
diff --git a/docs/components/yaml/attachments/dx1X0/top_plate.mdx b/docs/components/yaml/attachments/dx1X0/top_plate.mdx
new file mode 100644
index 000000000..be006c986
--- /dev/null
+++ b/docs/components/yaml/attachments/dx1X0/top_plate.mdx
@@ -0,0 +1,45 @@
+
+
+:::note
+All DX1X0 platforms allow for these mounting top plates to be easily added. However, the screw mounting locations are different, and therefore, the position of the top plate is slightly different on each platform.
+:::
+
+The height of the top plate can be adjusted using the `height` parameter. This parameter corresponds to the length of the stand-offs holding up the top plate. Therefore, the distance from the `parent` link to the top surface of the top plate will be `height` plus the thickness of the plate.
+
+Attach accessories to the top plate mounts by setting the accessory's `parent` parameter to one of the grid mounting locations displayed above. The grid mounting locations span from `top_plate_mount_a1` to `top_plate_mount_e6`, where the front left-most location is the `a1` mount and the bottom right-most location is the `e6` mount. The letters correspond to the columns and the number to the rows. The name of these links depends on the `name` parameter defined in the entry above.
+
+The `type` parameter can be set to any of `dd100.top_plate`, `dd150.top_plate`, `do100.top_plate`, or `do150.top_plate`, as all of these resolve in the same attachment.
diff --git a/docs/components/yaml/attachments/j100/fender_default.mdx b/docs/components/yaml/attachments/j100/fender_default.mdx
new file mode 100644
index 000000000..1adee6d14
--- /dev/null
+++ b/docs/components/yaml/attachments/j100/fender_default.mdx
@@ -0,0 +1,32 @@
+
+
+Attach accessories to the front and rear fender mounts by setting the accessory's `parent` parameter to `front_fender_mount` or `rear_fender_mount`. The mounts are displayed as axes in the image above.
diff --git a/docs/components/yaml/attachments/j100/img/fender_default.png b/docs/components/yaml/attachments/j100/img/fender_default.png
new file mode 100644
index 000000000..f0c4e68d0
Binary files /dev/null and b/docs/components/yaml/attachments/j100/img/fender_default.png differ
diff --git a/docs/components/yaml/attachments/j100/img/fender_sensor.png b/docs/components/yaml/attachments/j100/img/fender_sensor.png
new file mode 100644
index 000000000..72f3c26e8
Binary files /dev/null and b/docs/components/yaml/attachments/j100/img/fender_sensor.png differ
diff --git a/docs/components/yaml/attachments/j100/img/top_plate_ark_enclosure.png b/docs/components/yaml/attachments/j100/img/top_plate_ark_enclosure.png
new file mode 100644
index 000000000..2d8605a68
Binary files /dev/null and b/docs/components/yaml/attachments/j100/img/top_plate_ark_enclosure.png differ
diff --git a/docs/components/yaml/attachments/j100/top_plate_ark_enclosure.mdx b/docs/components/yaml/attachments/j100/top_plate_ark_enclosure.mdx
new file mode 100644
index 000000000..42a3772fb
--- /dev/null
+++ b/docs/components/yaml/attachments/j100/top_plate_ark_enclosure.mdx
@@ -0,0 +1,25 @@
+
+
+The height of the table can be adjusted using the `table_height` parameter. The height parameter corresponds to the length of the table legs. Therefore, the distance from the `parent` link to the top surface of the table will be the `table_height` plus the thickness of the top plate.
+
+Payloads can be added to the table using the links `fams_default_mount` (at the center of the table) and `fams_arm_mount` (at the front of the table). The name of these links corresponds to the `name` parameter set in the `robot.yaml`.
diff --git a/docs/components/yaml/attachments/r100/hams.mdx b/docs/components/yaml/attachments/r100/hams.mdx
new file mode 100644
index 000000000..d973673da
--- /dev/null
+++ b/docs/components/yaml/attachments/r100/hams.mdx
@@ -0,0 +1,32 @@
+
+
+The height of the table can be adjusted using the `table_height` parameter. The height parameter corresponds to the length of the table legs. Therefore, the distance from the `parent` link to the top surface of the table will be the `table_height` plus the thickness of the top plate.
+
+The height of the recessed arm mount can be adjusted using the `mount_height` parameter. The `mount_height` parameter corresponds to the distance from the `parent` link to the top surface of the mounting plate.
+
+Payloads can be added to the table using the links `hams_default_mount` (at the center of the table) and `hams_arm_mount` (center of the recessed plate). The name of these links corresponds to the `name` parameter set in the `robot.yaml`.
diff --git a/docs/components/yaml/attachments/r100/img/fams.png b/docs/components/yaml/attachments/r100/img/fams.png
new file mode 100644
index 000000000..dd5ea066a
Binary files /dev/null and b/docs/components/yaml/attachments/r100/img/fams.png differ
diff --git a/docs/components/yaml/attachments/r100/img/hams.png b/docs/components/yaml/attachments/r100/img/hams.png
new file mode 100644
index 000000000..a6cb6bd92
Binary files /dev/null and b/docs/components/yaml/attachments/r100/img/hams.png differ
diff --git a/docs/components/yaml/attachments/r100/img/tower.png b/docs/components/yaml/attachments/r100/img/tower.png
new file mode 100644
index 000000000..4ad1f5c64
Binary files /dev/null and b/docs/components/yaml/attachments/r100/img/tower.png differ
diff --git a/docs/components/yaml/attachments/r100/tower.mdx b/docs/components/yaml/attachments/r100/tower.mdx
new file mode 100644
index 000000000..7bcd7e19c
--- /dev/null
+++ b/docs/components/yaml/attachments/r100/tower.mdx
@@ -0,0 +1,30 @@
+
+
+The height of each arm mounting location or "shoulder" can be adjusted by using the `left_height` and `right_height` parameters. These height parameters correspond to the vertical distance from the lowest screw mounted location. There are seven screw mounting locations that are separated by 40 mm. The lowest mounting location corresponds to height `0.0` and the highest mounting location corresponds to height `0.28`. In the example above, the tower's right arm mount is set to height `0.0` and the tower's left arm is set to height `0.28`.
+
+Payloads can be added to the tower using the links: `tower_mid_link` (at the center of the tower), `tower_top_link` (at the top of the tower), `tower_left_shoulder_link` (at the center of the left tower mount), and `tower_right_shoulder_link` (at the center of the right tower mount). The name of these links corresponds to the `name` parameter set in the `robot.yaml`.
diff --git a/docs/components/yaml/attachments/w200/arm_mount.mdx b/docs/components/yaml/attachments/w200/arm_mount.mdx
new file mode 100644
index 000000000..2bc311716
--- /dev/null
+++ b/docs/components/yaml/attachments/w200/arm_mount.mdx
@@ -0,0 +1,26 @@
+
+
+Attach accessories to the arm plate mount by setting the accessory's `parent` parameter to `arm_plate_mount`. The mount is displayed as an axis in the image above.
diff --git a/docs/components/yaml/attachments/w200/bulkhead_arm_mount.mdx b/docs/components/yaml/attachments/w200/bulkhead_arm_mount.mdx
new file mode 100644
index 000000000..1a68629f7
--- /dev/null
+++ b/docs/components/yaml/attachments/w200/bulkhead_arm_mount.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the arm plate mount by setting the accessory's `parent` parameter to `arm_plate_mount`. The mount is displayed as an axis in the image above.
diff --git a/docs/components/yaml/attachments/w200/bulkhead_default.mdx b/docs/components/yaml/attachments/w200/bulkhead_default.mdx
new file mode 100644
index 000000000..87380f069
--- /dev/null
+++ b/docs/components/yaml/attachments/w200/bulkhead_default.mdx
@@ -0,0 +1,27 @@
+
+
+Attach accessories to the bulkhead by setting the accessory's `parent` parameter to `bulkhead_mount`. The mount is displayed as an axis in the image above.
diff --git a/docs/components/yaml/attachments/w200/generator.mdx b/docs/components/yaml/attachments/w200/generator.mdx
new file mode 100644
index 000000000..caa707b93
--- /dev/null
+++ b/docs/components/yaml/attachments/w200/generator.mdx
@@ -0,0 +1,24 @@
+
+
+#### Package and Setup
+:::note
+The Kinova 2F Lite gripper is the standard gripper on the Kinova Gen3 Lite. It is controlled via the arm's hardware interface and therefore, does not need it's own controller.
+:::
+The Kinova 2F Lite gripper uses the `kortex_description` and `kortex_driver` ROS 2 Packages. The driver is open source, maintaned by Kinova Robotics, and hosted on [GitHub](https://github.com/Kinovarobotics/ros2_kortex).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Kinova 2F Lite gripper [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/gripper/kinova_2f_lite.urdf.xacro) in `clearpath_manipulators_description`.
+
diff --git a/docs/components/yaml/manipulators/kinova_gen3_6dof.mdx b/docs/components/yaml/manipulators/kinova_gen3_6dof.mdx
new file mode 100644
index 000000000..2c54551c4
--- /dev/null
+++ b/docs/components/yaml/manipulators/kinova_gen3_6dof.mdx
@@ -0,0 +1,34 @@
+
+
+#### Package and Setup
+The Kinova Gen3 6Dof uses the `kortex_description` and `kortex_driver` ROS 2 Packages. The driver is open source, maintaned by Kinova Robotics, and hosted on [GitHub](https://github.com/Kinovarobotics/ros2_kortex).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Kinova Gen3 6Dof [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/arm/kinova_gen3_6dof.urdf.xacro) in `clearpath_manipulators_description`.
+
+#### Device IP and Port
+The `ip` and `port` parameters must be set to the corresponding values set on the manipulators configuration page.
diff --git a/docs/components/yaml/manipulators/kinova_gen3_7dof.mdx b/docs/components/yaml/manipulators/kinova_gen3_7dof.mdx
new file mode 100644
index 000000000..a390da42d
--- /dev/null
+++ b/docs/components/yaml/manipulators/kinova_gen3_7dof.mdx
@@ -0,0 +1,34 @@
+
+
+#### Package and Setup
+The Kinova Gen3 7Dof uses the `kortex_description` and `kortex_driver` ROS 2 Packages. The driver is open source, maintaned by Kinova Robotics, and hosted on [GitHub](https://github.com/Kinovarobotics/ros2_kortex).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Kinova Gen3 7Dof [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/arm/kinova_gen3_6dof.urdf.xacro) in `clearpath_manipulators_description`.
+
+#### Device IP and Port
+The `ip` and `port` parameters must be set to the corresponding values set on the manipulators configuration page.
diff --git a/docs/components/yaml/manipulators/kinova_gen3_lite.mdx b/docs/components/yaml/manipulators/kinova_gen3_lite.mdx
new file mode 100644
index 000000000..c6560fd3d
--- /dev/null
+++ b/docs/components/yaml/manipulators/kinova_gen3_lite.mdx
@@ -0,0 +1,34 @@
+
+
+#### Package and Setup
+The Kinova Gen3 Lite uses the `kortex_description` and `kortex_driver` ROS 2 Packages. The driver is open source, maintaned by Kinova Robotics, and hosted on [GitHub](https://github.com/Kinovarobotics/ros2_kortex).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Kinova Gen3 Lite [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/arm/kinova_gen3_lite.urdf.xacro) in `clearpath_manipulators_description`.
+
+#### Device IP and Port
+The `ip` and `port` parameters must be set to the corresponding values set on the manipulators configuration page.
diff --git a/docs/components/yaml/manipulators/robotiq_2f_140.mdx b/docs/components/yaml/manipulators/robotiq_2f_140.mdx
new file mode 100644
index 000000000..7470a7248
--- /dev/null
+++ b/docs/components/yaml/manipulators/robotiq_2f_140.mdx
@@ -0,0 +1,35 @@
+
+
+#### Package and Setup
+:::note
+The Robotiq 2F 140 gripper is supported by the Kinova Gen3 arm's wrist connector and hardware interface. Therefore, when attached to Kinova arm's the Robotiq gripper does not need it's own controller.
+:::
+The Robotiq 2F 140 uses the `robotiq_description` and `robotiq_driver` ROS 2 Packages. The driver is open source, maintaned by PickNik Robotics, and hosted on [GitHub](https://github.com/PickNikRobotics/ros2_robotiq_gripper).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Robotiq 2F 140 gripper [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/gripper/robotiq_2f_140.urdf.xacro) in `clearpath_manipulators_description`.
+
diff --git a/docs/components/yaml/manipulators/robotiq_2f_85.mdx b/docs/components/yaml/manipulators/robotiq_2f_85.mdx
new file mode 100644
index 000000000..e0321c787
--- /dev/null
+++ b/docs/components/yaml/manipulators/robotiq_2f_85.mdx
@@ -0,0 +1,35 @@
+
+
+#### Package and Setup
+:::note
+The Robotiq 2F 85 gripper is supported by the Kinova Gen3 arm's wrist connector and hardware interface. Therefore, when attached to Kinova arm's the Robotiq gripper does not need it's own controller.
+:::
+The Robotiq 2F 85 uses the `robotiq_description` and `robotiq_driver` ROS 2 Packages. The driver is open source, maintaned by PickNik Robotics, and hosted on [GitHub](https://github.com/PickNikRobotics/ros2_robotiq_gripper).
+
+For more specifics on the way Clearpath's configuration system adds the manipulator to the robot description, see the Robotiq 2F 85 gripper [description file](https://github.com/clearpathrobotics/clearpath_common/blob/humble/clearpath_manipulators_description/urdf/gripper/robotiq_2f_85.urdf.xacro) in `clearpath_manipulators_description`.
+
diff --git a/docs/components/yaml/mounts/bracket_horizontal.mdx b/docs/components/yaml/mounts/bracket_horizontal.mdx
new file mode 100644
index 000000000..c5a1b5ae8
--- /dev/null
+++ b/docs/components/yaml/mounts/bracket_horizontal.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the horizontal bracket by setting the accessory's `parent` parameter to `bracket_0_mount`.
diff --git a/docs/components/yaml/mounts/bracket_large.mdx b/docs/components/yaml/mounts/bracket_large.mdx
new file mode 100644
index 000000000..f0c1faf9a
--- /dev/null
+++ b/docs/components/yaml/mounts/bracket_large.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the large bracket by setting the accessory's `parent` parameter to `bracket_0_mount`.
diff --git a/docs/components/yaml/mounts/bracket_vertical.mdx b/docs/components/yaml/mounts/bracket_vertical.mdx
new file mode 100644
index 000000000..f9242b487
--- /dev/null
+++ b/docs/components/yaml/mounts/bracket_vertical.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the vertical bracket by setting the accessory's `parent` parameter to `bracket_0_mount` or `bracket_0_vertical_mount`.
diff --git a/docs/components/yaml/mounts/disk.mdx b/docs/components/yaml/mounts/disk.mdx
new file mode 100644
index 000000000..43da02f59
--- /dev/null
+++ b/docs/components/yaml/mounts/disk.mdx
@@ -0,0 +1,23 @@
+
+
+Attach an accessory to the disk post mount by setting the accessory's `parent` parameter to `disk_0_mount`.
diff --git a/docs/components/yaml/mounts/disk_post.mdx b/docs/components/yaml/mounts/disk_post.mdx
new file mode 100644
index 000000000..2f0060014
--- /dev/null
+++ b/docs/components/yaml/mounts/disk_post.mdx
@@ -0,0 +1,30 @@
+
+
+Attach an accessory to the disk post mount by setting the accessory's `parent` parameter to `disk_0_mount`.
diff --git a/docs/components/yaml/mounts/fath_pivot.mdx b/docs/components/yaml/mounts/fath_pivot.mdx
new file mode 100644
index 000000000..3e1243e01
--- /dev/null
+++ b/docs/components/yaml/mounts/fath_pivot.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the post by setting the accessory's `parent` parameter to `post_0_mount`.
diff --git a/docs/components/yaml/mounts/post_quad.mdx b/docs/components/yaml/mounts/post_quad.mdx
new file mode 100644
index 000000000..2c6890bc5
--- /dev/null
+++ b/docs/components/yaml/mounts/post_quad.mdx
@@ -0,0 +1,26 @@
+
+
+Attach an accessory to the post by setting the accessory's `parent` parameter to `post_0_mount`.
diff --git a/docs/components/yaml/mounts/post_single.mdx b/docs/components/yaml/mounts/post_single.mdx
new file mode 100644
index 000000000..00b078f8e
--- /dev/null
+++ b/docs/components/yaml/mounts/post_single.mdx
@@ -0,0 +1,25 @@
+
+
+Attach an accessory to the post by setting the accessory's `parent` parameter to `post_0_mount`.
diff --git a/docs/components/yaml/mounts/riser_1x7.mdx b/docs/components/yaml/mounts/riser_1x7.mdx
new file mode 100644
index 000000000..c307ded12
--- /dev/null
+++ b/docs/components/yaml/mounts/riser_1x7.mdx
@@ -0,0 +1,28 @@
+
+
+Attach an accessory to the riser by setting the accessory's `parent` parameter to one of the mounts, `riser_0_mount_a1` to `riser_0_mount_g1`.
+
+The mounting location names are based of the existing grid. If the riser is added to the second row instead by setting the `parent` parameter to `top_plate_mount_a2`, then the mounts will be named `riser_0_mount_a2` to `riser_0_mount_g1`.
diff --git a/docs/components/yaml/mounts/riser_4x4.mdx b/docs/components/yaml/mounts/riser_4x4.mdx
new file mode 100644
index 000000000..12520353b
--- /dev/null
+++ b/docs/components/yaml/mounts/riser_4x4.mdx
@@ -0,0 +1,28 @@
+
+
+Attach an accessory to the riser by setting the accessory's `parent` parameter to one of the mounts, `riser_0_mount_a1` to `riser_0_mount_d4`.
+
+The mounting location names are based of the existing grid. If the riser is added to the second row instead by setting the `parent` parameter to `top_plate_mount_a2`, then the mounts will be named `riser_0_mount_a2` to `riser_0_mount_d5`.
diff --git a/docs/components/yaml/mounts/riser_8x7.mdx b/docs/components/yaml/mounts/riser_8x7.mdx
new file mode 100644
index 000000000..0617658b3
--- /dev/null
+++ b/docs/components/yaml/mounts/riser_8x7.mdx
@@ -0,0 +1,28 @@
+
+
+Attach an accessory to the riser by setting the accessory's `parent` parameter to one of the mounts, `riser_0_mount_a1` to `riser_0_mount_g8`.
+
+It is not recommended to change the parent link of the 8 x 7 riser as it will not align with the top plate.
diff --git a/docs/components/yaml/mounts/sick_inverted.mdx b/docs/components/yaml/mounts/sick_inverted.mdx
new file mode 100644
index 000000000..029d6c7ca
--- /dev/null
+++ b/docs/components/yaml/mounts/sick_inverted.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the SICK mount by setting the accessory's `parent` parameter to `sick_0_mount`.
diff --git a/docs/components/yaml/mounts/sick_upright.mdx b/docs/components/yaml/mounts/sick_upright.mdx
new file mode 100644
index 000000000..a8b983bdc
--- /dev/null
+++ b/docs/components/yaml/mounts/sick_upright.mdx
@@ -0,0 +1,24 @@
+
+
+Attach an accessory to the SICK mount by setting the accessory's `parent` parameter to `sick_0_mount`.
diff --git a/docs/components/yaml/sensors/chrobotics_um6.mdx b/docs/components/yaml/sensors/chrobotics_um6.mdx
new file mode 100644
index 000000000..d5cb6ba78
--- /dev/null
+++ b/docs/components/yaml/sensors/chrobotics_um6.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The CHRobotics UM6 IMU uses the `umx_driver` ROS 2 package. The driver is open source, maintained by the ROS community, and hosted on [GitHub](https://github.com/ros-drivers/um7).
+
+For more specifics on the way Clearpath's configuration system launches the `umx_driver`, see the CHRobotics UM6 [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/chrobotics_um6.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/chrobotics_um6.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the CHRobotics UM6. To simplify this process, use the `/dev/clearpath/imu` path. This path is only available when the Clearpath robot UDEV rules are installed. These are installed alongside the `clearpath_robot` package. If the IMU is connected, but the `/dev/clearpath/imu` device is not, check the file `/lib/udev/rules.d/60-ros-humble-clearpath-robot.rules` exists.
diff --git a/docs/components/yaml/sensors/flir_blackfly.mdx b/docs/components/yaml/sensors/flir_blackfly.mdx
new file mode 100644
index 000000000..0246c72bb
--- /dev/null
+++ b/docs/components/yaml/sensors/flir_blackfly.mdx
@@ -0,0 +1,76 @@
+
+
+#### Package and Setup
+The Flir Blackfly cameras use the `spinnaker_camera_driver` ROS 2 package. The driver is open source, maintained by the ROS community, and hosted on [GitHub](https://github.com/ros-drivers/flir_camera_driver). The `spinnaker_camera_driver` depends on the [Spinnaker SDK](https://www.flir.ca/products/spinnaker-sdk/), which is installed automatically alongside the package.
+
+Before using the camera, the computer needs further setup. The setup can be done automatically using the [linux setup script](https://github.com/ros-drivers/flir_camera_driver/blob/humble-devel/spinnaker_camera_driver/scripts/linux_setup_flir):
+
+```bash
+ros2 run spinnaker_camera_driver linux_setup_flir
+```
+
+Or, manually by following the [instructions on the GitHub README](https://github.com/ros-drivers/flir_camera_driver/blob/humble-devel/spinnaker_camera_driver/docs/linux_setup_flir.md).
+
+For specifics on the way Clearpath's configuration system launches the camera, see the Flir Blackfly [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/flir_blackfly.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/flir_blackfly.yaml) in `clearpath_sensors`.
+
+#### Serial Number
+The `serial_number` parameter must be set to successfully launch the node. The serial number can be found on the label on the camera. However, if this label is not available and the camera is a USB camera, connect the camera to the computer and use `lsusb` to its three digit `Bus` and `Device` number. Then, find the serial number using the following command, replacing `BUS` and `DEV` with the three digit numbers found in the previous step:
+```bash
+udevadm info --attribute-walk /dev/bus/usb/BUS/DEV | grep -i serial
+```
+
+The resulting output of the command should appear as:
+```bash
+ATTR{serial}=="013686A9"
+```
+
+Then, convert attirbute serial hexadecimal value to decimal representation and set it to the `serial_number` parameter. Convert values from hexadecimal to decimal representation using the following terminal command, where `HEX` needs to be swapped with the hexadecimal value:
+```bash
+echo $((16#HEX))
+```
+
+For the example above, the hexadecimal serial number `013686A9` would be converted to `20350633`. Use the decimal representation to set the parameter: `serial_number: 20350633`.
+
+#### Resolution
+The `image_height` and `image_width` parameters define the area of the raw image to crop. It does not downsample the image. Use the `offset_x` and `offset_y` parameters to change the origin of the cropped area. These parameters would be best used to define an area of interest.
+
+To reduce the size of the image using downsamlping, use the `binning_x` and `binning_y` parameters. These parameters define the number of pixels that will be binned together in each axis. If both `binning_x` and `binning_y` are set to `2`, then the resolution of the image will be halved.
+
+Reducing the resolution of the image improves the perfomance of the camera driver and network transit of image packets.
diff --git a/docs/components/yaml/sensors/garmin_18x.mdx b/docs/components/yaml/sensors/garmin_18x.mdx
new file mode 100644
index 000000000..b9209a43a
--- /dev/null
+++ b/docs/components/yaml/sensors/garmin_18x.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The Garmin 18x GPS sensor uses the `nmea_navsat_driver` ROS 2 driver. The driver is open source, maintained by the community, and hosted on [GitHub](https://github.com/ros-drivers/nmea_navsat_driver).
+
+For specifics on the way Clearpath's configuration system launches the sensor driver, see the Garmin 18x [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/garmin_18x.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/garmin_18x.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the Garmin 18x. To simplify this process, use the `/dev/clearpath/gps` path. This path is only available when the Clearpath robot UDEV rules are installed. These are installed alongside the `clearpath_robot` package. If the receiver is connected, but the `/dev/clearpath/gps` device is not, check the file `/lib/udev/rules.d/60-ros-humble-clearpath-robot.rules` exists.
diff --git a/docs/components/yaml/sensors/hokuyo_ust.mdx b/docs/components/yaml/sensors/hokuyo_ust.mdx
new file mode 100644
index 000000000..f6986c06f
--- /dev/null
+++ b/docs/components/yaml/sensors/hokuyo_ust.mdx
@@ -0,0 +1,35 @@
+
+
+#### Package and Setup
+The Hokuyo UST uses the `urg_node` ROS 2 package. The driver is open source, maintained by the ROS community, and hosted on [GitHub](https://github.com/ros-drivers/urg_node).
+
+For more specifics on the way the Clearpath's configuration system launches the driver, see the Hokuyo UST [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/hokuyo_ust.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/hokuyo_ust.yaml) in `clearpath_sensors`.
diff --git a/docs/components/yaml/sensors/img/chrobotics_um6.png b/docs/components/yaml/sensors/img/chrobotics_um6.png
new file mode 100644
index 000000000..2b76338df
Binary files /dev/null and b/docs/components/yaml/sensors/img/chrobotics_um6.png differ
diff --git a/docs/components/yaml/sensors/img/flir_blackfly.png b/docs/components/yaml/sensors/img/flir_blackfly.png
new file mode 100644
index 000000000..86be822a4
Binary files /dev/null and b/docs/components/yaml/sensors/img/flir_blackfly.png differ
diff --git a/docs/components/yaml/sensors/img/garmin_18x.png b/docs/components/yaml/sensors/img/garmin_18x.png
new file mode 100644
index 000000000..df967a4b3
Binary files /dev/null and b/docs/components/yaml/sensors/img/garmin_18x.png differ
diff --git a/docs/components/yaml/sensors/img/hokuyo_ust.png b/docs/components/yaml/sensors/img/hokuyo_ust.png
new file mode 100644
index 000000000..b1f6bce13
Binary files /dev/null and b/docs/components/yaml/sensors/img/hokuyo_ust.png differ
diff --git a/docs/components/yaml/sensors/img/intel_realsense.png b/docs/components/yaml/sensors/img/intel_realsense.png
new file mode 100644
index 000000000..9d64fa627
Binary files /dev/null and b/docs/components/yaml/sensors/img/intel_realsense.png differ
diff --git a/docs/components/yaml/sensors/img/microstrain_gq7.png b/docs/components/yaml/sensors/img/microstrain_gq7.png
new file mode 100644
index 000000000..d9764b9e1
Binary files /dev/null and b/docs/components/yaml/sensors/img/microstrain_gq7.png differ
diff --git a/docs/components/yaml/sensors/img/microstrain_imu.png b/docs/components/yaml/sensors/img/microstrain_imu.png
new file mode 100644
index 000000000..2b76338df
Binary files /dev/null and b/docs/components/yaml/sensors/img/microstrain_imu.png differ
diff --git a/docs/components/yaml/sensors/img/novatel_smart6.png b/docs/components/yaml/sensors/img/novatel_smart6.png
new file mode 100644
index 000000000..1b3aeae86
Binary files /dev/null and b/docs/components/yaml/sensors/img/novatel_smart6.png differ
diff --git a/docs/components/yaml/sensors/img/novatel_smart7.png b/docs/components/yaml/sensors/img/novatel_smart7.png
new file mode 100644
index 000000000..b2579da1e
Binary files /dev/null and b/docs/components/yaml/sensors/img/novatel_smart7.png differ
diff --git a/docs/components/yaml/sensors/img/redshift_um7.png b/docs/components/yaml/sensors/img/redshift_um7.png
new file mode 100644
index 000000000..2b76338df
Binary files /dev/null and b/docs/components/yaml/sensors/img/redshift_um7.png differ
diff --git a/docs/components/yaml/sensors/img/sick_lms1xx.png b/docs/components/yaml/sensors/img/sick_lms1xx.png
new file mode 100644
index 000000000..59f9e980e
Binary files /dev/null and b/docs/components/yaml/sensors/img/sick_lms1xx.png differ
diff --git a/docs/components/yaml/sensors/img/stereolabs_zed.png b/docs/components/yaml/sensors/img/stereolabs_zed.png
new file mode 100644
index 000000000..38c6be785
Binary files /dev/null and b/docs/components/yaml/sensors/img/stereolabs_zed.png differ
diff --git a/docs/components/yaml/sensors/img/swiftnav_duro.png b/docs/components/yaml/sensors/img/swiftnav_duro.png
new file mode 100644
index 000000000..69affe668
Binary files /dev/null and b/docs/components/yaml/sensors/img/swiftnav_duro.png differ
diff --git a/docs/components/yaml/sensors/img/velodyne_lidar.png b/docs/components/yaml/sensors/img/velodyne_lidar.png
new file mode 100644
index 000000000..e57dc2172
Binary files /dev/null and b/docs/components/yaml/sensors/img/velodyne_lidar.png differ
diff --git a/docs/components/yaml/sensors/intel_realsense.mdx b/docs/components/yaml/sensors/intel_realsense.mdx
new file mode 100644
index 000000000..a1459aac2
--- /dev/null
+++ b/docs/components/yaml/sensors/intel_realsense.mdx
@@ -0,0 +1,58 @@
+
+
+#### Package and Setup
+The Intel Realsense cameras use the `realsense_ros` ROS 2 driver. The driver is open source, maintained by Intel, and hosted on [GitHub](https://github.com/IntelRealSense/realsense-ros). The `realsense_ros` nodes depends on the the `librealsense2` [SDK](https://github.com/IntelRealSense/librealsense). Both packages will be installed alongside the `clearpath_sensors` package.
+
+For specifics on the way Clearpath's configuration system launches the camera, see the Intel Realsense [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/intel_realsense.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/intel_realsense.yaml) in `clearpath_sensors`.
+
+#### Device Type and Serial Number
+The `device_type` and `serial_no` parameters must be set accurately to successfully launch the node. Both of these values can be found using the SDK utility.
+
+Use the following command to see a list of connected Intel Realsense devices:
+```bash
+rs-fw-update
+```
+
+When ran without any arguments, the `rs-fw-update` will return information about the connected devices, as is shown below:
+```bash
+Nothing to do, run again with -h for help
+
+Connected devices:
+1) Name: Intel RealSense D435, serial number: 045322073417, update serial number: 041323020523, firmware version: 5.12.13.50, USB type: 3.2
+```
+
+The `device_type` is the alpha-numerical sequence in the name. In the example above, set `device_type` to `d435`.
+
+The `serial_no` is the string following the serial number entry. In the example above, set `serial_no` to `"045322073417"`. Make sure to use quotes to ensure that the serial number is interpreted as a string.
diff --git a/docs/components/yaml/sensors/microstrain_gq7.mdx b/docs/components/yaml/sensors/microstrain_gq7.mdx
new file mode 100644
index 000000000..e6fc200d0
--- /dev/null
+++ b/docs/components/yaml/sensors/microstrain_gq7.mdx
@@ -0,0 +1,38 @@
+
+
+#### Package and Setup
+The MicroStrain GQ7 sensor uses the `microstrain_inertial_driver` ROS 2 driver. The driver is open source, maintained by MicroStrain by HBK, and hosted on [GitHub](https://github.com/LORD-MicroStrain/microstrain_inertial/tree/ros2).
+
+For specifics on the way Clearpath's configuration system launches the sensor driver, see the MicroStrain GQ7 [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/microstrain_gq7.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/microstrain_gq7.yaml) in `clearpath_sensors`.
+
+For a list of all possible parameters and documentation on what they do, see the [params.yml](https://github.com/LORD-MicroStrain/microstrain_inertial_driver_common/blob/main/config/params.yml) provided by the `microstrain_inertial_driver`
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the MicroStrain GQ7. To simplify this process, use the `/dev/microstrain_main` or `/dev/microstrain_main_` path. This path is only available when the MicroStrain UDEV rules are installed. These are installed alongside the `microstrain_inertial_driver` package. If the receiver is connected, but the `/dev/microstrain_main` device is not, check the file `/lib/udev/rules.d/60-ros-humble-microstrain-inertial-driver.rules` exists.
diff --git a/docs/components/yaml/sensors/microstrain_imu.mdx b/docs/components/yaml/sensors/microstrain_imu.mdx
new file mode 100644
index 000000000..9adf04177
--- /dev/null
+++ b/docs/components/yaml/sensors/microstrain_imu.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The MicroStrain GX devices use the `microstain_inertial` ROS 2 package. The driver is open source, maintained by MicroStrain, and hosted on [GitHub](https://github.com/LORD-MicroStrain/microstrain_inertial).
+
+For more specifics on the way Clearpath's configuration system launches the `microstrain_inertial` driver, see the MicroStrain GX [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/microstrain_imu.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/microstrain_imu.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the MicroStrain device. The `microstrain_inertial` package installs its UDEV rule, which will add the `/dev/microstrain_main` device.
diff --git a/docs/components/yaml/sensors/novatel_smart6.mdx b/docs/components/yaml/sensors/novatel_smart6.mdx
new file mode 100644
index 000000000..d82bc1c47
--- /dev/null
+++ b/docs/components/yaml/sensors/novatel_smart6.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The Novatel Smart6 GNSS antenna uses the `nmea_navsat_driver` ROS 2 driver. The driver is open source, maintained by the community, and hosted on [GitHub](https://github.com/ros-drivers/nmea_navsat_driver).
+
+For specifics on the way Clearpath's configuration system launches the sensor driver, see the Novatel Smart6 [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/novatel_smart6.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/novatel_smart6.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the Novatel Smart6. To simplify this process, use the `/dev/clearpath/gps` path. This path is only available when the Clearpath robot UDEV rules are installed. These are installed alongside the `clearpath_robot` package. If the receiver is connected, but the `/dev/clearpath/gps` device is not, check the file `/lib/udev/rules.d/60-ros-humble-clearpath-robot.rules` exists.
diff --git a/docs/components/yaml/sensors/novatel_smart7.mdx b/docs/components/yaml/sensors/novatel_smart7.mdx
new file mode 100644
index 000000000..c7ccec5ba
--- /dev/null
+++ b/docs/components/yaml/sensors/novatel_smart7.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The Novatel Smart7 GNSS antenna uses the `nmea_navsat_driver` ROS 2 driver. The driver is open source, maintained by the community, and hosted on [GitHub](https://github.com/ros-drivers/nmea_navsat_driver).
+
+For specifics on the way Clearpath's configuration system launches the sensor driver, see the Navsat Smart7 [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/novatel_smart7.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/novatel_smart7.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the Novatel Smart7. To simplify this process, use the `/dev/clearpath/gps` path. This path is only available when the Clearpath robot UDEV rules are installed. These are installed alongside the `clearpath_robot` package. If the receiver is connected, but the `/dev/clearpath/gps` device is not, check the file `/lib/udev/rules.d/60-ros-humble-clearpath-robot.rules` exists.
diff --git a/docs/components/yaml/sensors/redshift_um7.mdx b/docs/components/yaml/sensors/redshift_um7.mdx
new file mode 100644
index 000000000..1fc13fbb1
--- /dev/null
+++ b/docs/components/yaml/sensors/redshift_um7.mdx
@@ -0,0 +1,36 @@
+
+
+#### Package and Setup
+The RedShift UM7 IMU uses the `umx_driver` ROS 2 package. The driver is open source, maintained by the ROS community, and hosted on [GitHub](https://github.com/ros-drivers/um7).
+
+For more specifics on the way Clearpath's configuration system launches the `umx_driver`, see the RedShift UM7 [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/chrobotics_um6.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/chrobotics_um6.yaml) in `clearpath_sensors`.
+
+#### Device Path
+The `port` ROS parameter must be set to the device path of the RedShift UM7. To simplify this process, use the `/dev/clearpath/imu` path. This path is only available when the Clearpath robot UDEV rules are installed. These are installed alongside the `clearpath_robot` package. If the IMU is connected, but the `/dev/clearpath/imu` device is not, check the file `/lib/udev/rules.d/60-ros-humble-clearpath-robot.rules` exists.
diff --git a/docs/components/yaml/sensors/sick_lms1xx.mdx b/docs/components/yaml/sensors/sick_lms1xx.mdx
new file mode 100644
index 000000000..160dce179
--- /dev/null
+++ b/docs/components/yaml/sensors/sick_lms1xx.mdx
@@ -0,0 +1,33 @@
+
+
+#### Package and Setup
+The SICK LMS1xx laser scan uses the `lms1xx` ROS 2 package. The driver is open source, maintained by Clearpath, and hosted on [GitHub](https://github.com/clearpathrobotics/lms1xx).
+
+For more specifics on the way Clearpath's configuration system launches the `lms1xx` driver, see the SICK LMS1xx [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/sick_lms1xx.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/sick_lms1xx.yaml) in `clearpath_sensors`.
diff --git a/docs/components/yaml/sensors/stereolabs_zed.mdx b/docs/components/yaml/sensors/stereolabs_zed.mdx
new file mode 100644
index 000000000..a1db9d9b0
--- /dev/null
+++ b/docs/components/yaml/sensors/stereolabs_zed.mdx
@@ -0,0 +1,55 @@
+
+
+#### Package and Setup
+The Stereolabs Zed cameras use the `zed-ros2-wrapper` ROS 2 driver. The driver is open source, maintained by Stereolabs, and hosted on [GitHub](https://github.com/stereolabs/zed-ros2-wrapper). The `zed_wrapper` nodes depend on the the [ZED SDK](https://www.stereolabs.com/developers/release). The `zed-ros2-wrapper` ROS packages and the ZED SDK **are not installed by ROS dependencies** because the SDK and the wrapper depend on CUDA and need to be built against the specific version installed on your computer. Therefore, **you will have to install these manually by following the instructions in the [`zed-ros2-wrapper`](https://github.com/stereolabs/zed-ros2-wrapper/blob/master/README.md) repository.
+
+For specifics on the way Clearpath's configuration system launches the camera, see the Stereolabs Zed [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/stereolabs_zed.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/stereolabs_zed.yaml) in `clearpath_sensors`.
+
+#### Camera Model
+The `general.camera_model` parameter must be modified to the match the type of Zed camera being used. See the list below for all models:
+- `zed`
+- `zedm`
+- `zed2`
+- `zed2i`
+- `zedx`
+- `zedxm`
+- `virtual`
+
+#### Serial Number
+The `general.serial_number` parameter can be left at `0` if only one camera is connected to that computer. If multiple cameras are connected, make sure to define a serial number for each.
+
+#### Resolution
+The `general.grab_resolution` parameter can be modified to change the resolution preset of the camera. Not all cameras support all presets. See the list below for all presets:
+- `AUTO`
+- `HD2K`
+- `HD1080`
+- `HD720`
+- `VGA`
diff --git a/docs/components/yaml/sensors/swiftnav_duro.mdx b/docs/components/yaml/sensors/swiftnav_duro.mdx
new file mode 100644
index 000000000..00443b4ed
--- /dev/null
+++ b/docs/components/yaml/sensors/swiftnav_duro.mdx
@@ -0,0 +1,70 @@
+
+
+#### Package and Setup
+The SwiftNav Duro uses the `duro_gps_driver` ROS 2 driver. The driver is open source, maintained by the autonomous vehicle development team of Széchenyi University, and hosted on [GitHub](https://github.com/szenergy/duro_gps_driver).
+
+The `duro_gps_driver` and its dependency `libsbp`, the Swift binary protocol libray, must be built from source.
+
+Build and install the `libsbp`:
+```bash
+
+# Install build dependencies.
+sudo apt-get install build-essential pkg-config cmake doxygen check
+# Clone driver to home directory
+cd ~
+git clone https://github.com/swift-nav/libsbp.git
+# Checkout latest supported branch
+cd libsbp
+git checkout e149901e63ddcdb0d818adcd8f8e4dbd0e2738d6
+# Update submodules
+cd c
+git submodule update --init --recursive
+# Build and install
+mkdir build; cd build
+cmake ../
+make
+sudo make install
+
+```
+
+Build the `duro_gps_driver` in the ROS workspace.
+```bash
+
+# Clone driver to source directory
+cd ~/colcon_ws/src
+git clone https://github.com/szenergy/duro_gps_driver -b ros2-humble
+# Build the driver
+cd ~/colcon_ws
+colcon build --packages-select duro_gps_driver
+
+```
+
+For specifics on the way Clearpath's configuration system launches the `duro_gps_driver`, see the SwiftNav Duro [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/swiftnav_duro.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/swiftnav_duro.yaml) in `clearpath_sensors`.
diff --git a/docs/components/yaml/sensors/velodyne_lidar.mdx b/docs/components/yaml/sensors/velodyne_lidar.mdx
new file mode 100644
index 000000000..5e196983a
--- /dev/null
+++ b/docs/components/yaml/sensors/velodyne_lidar.mdx
@@ -0,0 +1,79 @@
+
+
+#### Package and Setup
+The Velodyne LiDARs use the `velodyne_driver` ROS 2 Package. The driver is open source, maintained by the ROS community, and hosted on [GitHub](https://github.com/ros-drivers/velodyne). Unlike other drivers, the visual description of the device is hosted in a separate repository. The description package, along with the simulator, is maintained by Dataspeed and hosted on [BitBucket](https://bitbucket.org/DataspeedInc/velodyne_simulator).
+
+For more specifics on the way Clearpath's configuration system launches the `velodyne_driver`, see the Velodyne [launch file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/launch/velodyne_lidar.launch.py) and the [default parameter file](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_sensors/config/velodyne_lidar.yaml) in `clearpath_sensors`.
+
+#### Model
+There are several types of Velodyne LiDAR. To switch between these, the `model` parameter must be set under the both the `velodyne_driver_node` and the `velodyne_transform_node`, and the `calibration` parameter must be set under the `velodyne_transform_node`.
+
+| Name | Model | Calibration |
+|------|-------|-------------|
+|Puck|"VLP16"|"VLP16db.yaml"|
+|Puck Hi-Res|"VLP16"|"VLP16_hires_db.yaml"|
+|Ultra Puck|"32C"|"VeloView-VLP-32C.yaml"|
+|VLS-128|"VLS128"|"VLS128.yaml"|
+|HDL-32E|"32E"|"32db.yaml"|
+|HDL-64E|"64E"|"64e_utexas.yaml"|
+|HDL-64ES2|"64E_S2"|"64e_s2.1-sztaki.yaml"|
+|HDL-64ES3|"64E_S3"|"64e_s3-xiesc.yaml"|
+
+When setting the `calibration` parameter, prepend the path `/opt/ros/humble/share/velodyne_pointcloud/params/` to the calibration file name in the table above.
+
diff --git a/docs/robots/accessories/_category_.json b/docs/robots/accessories/_category_.json
new file mode 100644
index 000000000..78c643b7c
--- /dev/null
+++ b/docs/robots/accessories/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Accessories",
+ "position": 6
+}
diff --git a/docs/robots/accessories/accessories.mdx b/docs/robots/accessories/accessories.mdx
new file mode 100644
index 000000000..d4f8c8c9f
--- /dev/null
+++ b/docs/robots/accessories/accessories.mdx
@@ -0,0 +1,17 @@
+---
+title: Accessories Overview
+sidebar_label: Accessories Overview
+sidebar_position: 6
+---
+
+Many different types of accessories can be added onto Clearpath robot platforms to suit your specific needs.
+
+:::info links to accessory pages
+
+- [Computers](computers/computers.mdx)
+- [Sensors](sensors/sensors.mdx)
+- [Manipulators](manipulators/manipulators.mdx)
+- [PACS™](pacs.mdx)
+- [Add-ons](add-ons/add-ons.mdx)
+
+:::
diff --git a/docs/robots/accessories/add-ons/_category_.json b/docs/robots/accessories/add-ons/_category_.json
new file mode 100644
index 000000000..e4c5c20a4
--- /dev/null
+++ b/docs/robots/accessories/add-ons/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Add-ons",
+ "position": 6
+}
diff --git a/docs/robots/accessories/add-ons/add-ons.mdx b/docs/robots/accessories/add-ons/add-ons.mdx
new file mode 100644
index 000000000..946cf0251
--- /dev/null
+++ b/docs/robots/accessories/add-ons/add-ons.mdx
@@ -0,0 +1,35 @@
+---
+title: Add-ons Overview
+sidebar_label: Add-ons
+sidebar_position: 1
+---
+
+
+
+
+
+The following pages list add-on subsystems to support our base robot platforms and sensors.
+Thses pages will list subsystems like:
+
+- Wi-Fi and networking
+- Lights
+- Controllers
+- Power Supplies
+- Cabling and Electrical considerations
+- Brackets and Mechanical considerations
+
+We suggest you:
+
+1. Review our documentation of these accessories.
+2. If you want Clearpath Robotics to integrate accessories on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+3. Contact our Support team at \ if you have any questions.
diff --git a/docs/robots/accessories/add-ons/base_station.mdx b/docs/robots/accessories/add-ons/base_station.mdx
new file mode 100644
index 000000000..704525ce0
--- /dev/null
+++ b/docs/robots/accessories/add-ons/base_station.mdx
@@ -0,0 +1,42 @@
+---
+title: Base Station
+sidebar_position: 2
+---
+
+
+
+
+ Base Station with GPS
+
+
+
+Our Base Station is a Network Access Point inside a weatherproof enclosure.
+
+It includes:
+
+- A weatherproof enclosure mounted to a tripod
+- A network access point and antenna to create a Wi-Fi network
+- An AC-DC power supply
+- A battery and charger, so you can use the Base Station remotely
+
+Our robots are configured to automatically connect to the Base Station's Wi-Fi network.
+You can then connect your development computer to the Base Station through Wi-Fi or a network cable, and then share data with the robot over Wi-Fi.
+Our standard Base Station can send data at 100 Mbit/s at up to 100 metres range.
+
+We also have a GPS variant of the Base Station where we add a [Swift Navigation Duro](../sensors/gps/swift_navigation_duro.mdx) to the system, connecting it to the Access Point with a network cable.
+This GPS sensor allows the robot to apply an RTK (Real-Time Kinematic) correction for more accurate localization.
+
+:::note
+
+Clearpath uses this RTK correction in its OutdoorNav autonomy software, but we do not use this data in the standard _/odometry_ rostopic.
+
+:::
+
+:::note
+
+Refer to the [Network IP Addresses page](../../../ros/networking/network_ip_addresses.mdx) for the commonly used device IP addresses.
+
+:::
diff --git a/docs/robots/accessories/add-ons/controllers.mdx b/docs/robots/accessories/add-ons/controllers.mdx
new file mode 100644
index 000000000..266c61c35
--- /dev/null
+++ b/docs/robots/accessories/add-ons/controllers.mdx
@@ -0,0 +1,104 @@
+---
+title: Controllers
+sidebar_position: 3
+---
+
+| Description | CPR Item |
+| :------------------------------------------------------------------ | :------- |
+| [Logitech F710](#controllers_logitech_f710) | 002071 |
+| [Sony Dualshock](#controllers_sony_dualshock) | 011756 |
+| [Futaba 4GRS](#controllers_futaba_4grs) | 011389 |
+| [FORT Robotics Safe Remote Control](#controllers_fort_robotics_src) | 025725 |
+
+Controllers appear in Ubuntu in the _/dev/input/_ directory.
+Navigate to that directory,and then run `ls` to list the controllers.
+You can view the data stream of the controller by running `jstest /dev/input/js0`, changing the final value to the relevent controller.
+
+:::note
+
+You may need to install _jstest_ with `sudo apt-get install jstest-gtk`
+
+:::
+
+Clearpath uses the _/bluetooth_teleop_ ROS node to publish velocity commands from the joystick to _/twist_mux_.
+_/twist_mux_ Takes in multiple sources of velocity commands, and prioritizes what actually gets sent to _/cmd_vel_ to drive the robot.
+
+Depending on the robot platform and related controller, you will need to configure your robot's [robot.yaml configuration file](../../../ros/config/yaml/platform/controller.mdx).
+
+---
+
+## Logitech F710 {#controllers_logitech_f710}
+
+
+
+
+
+
+
+Drivers are included in the current Linux Kernels that Clearpath Robotics uses.
+
+The included USB dongle requires a line-of-sight connection with the handheld controller.
+
+---
+
+## Sony Dualshock {#controllers_sony_dualshock}
+
+
+
+
+
+
+
+This conroller requires a Bluetooth connection to the robot's computer.
+
+Linux Driver: https://github.com/clearpathrobotics/ds4drv
+
+---
+
+## Futaba 4GRS {#controllers_futaba_4grs}
+
+
+
+
+
+
+
+This controller includes a PCBA that sends data to the ROS computer with a serial connection.
+
+The controller communicates with the PCBA receiver over a 2.4 GHz radio.
+
+Clearpath Robotics has built this controller into the Warthog and Moose platforms.
+
+It can be integrated on other robots, but requires custom integration as there is not an Open Source ROS driver at this time.
+
+---
+
+## FORT Robotics controller {#controllers_fort_robotics_src}
+
+
+
+
+
+
+
+Similar to the Logitech controller listed above, the FORT Robotics controller data appears in _/dev/input/_ and uses a Linux Driver included in the current Ubuntu LTS release.
+
+The controller and receiver communicate over a 900 MHz radio, with the specific band configured based on your country.
+
+:::note
+
+The status of the motion-stop button does appear in the data, as well as the other buttons and joysticks.
+
+:::
diff --git a/docs/robots/accessories/add-ons/din_rail.mdx b/docs/robots/accessories/add-ons/din_rail.mdx
new file mode 100644
index 000000000..235b8e2fc
--- /dev/null
+++ b/docs/robots/accessories/add-ons/din_rail.mdx
@@ -0,0 +1,104 @@
+---
+title: DIN rail
+sidebar_position: 4
+---
+
+
+
+
+
+
+
+
+
+## Kits
+
+| Description | CPR Item |
+| :-------------------------------- | :------: |
+| Kit, Attachment—80 X 80, DIN Rail | 027881 |
+
+## DIN Rail Lengths
+
+
+ Click to expand
+
+
+The OutdoorNav Starter Kit is a low-cost hardware bundle that allows you to begin autonomous outdoor navigation using
+Clearpath's [OutdoorNav Autonomy Software](/docs_outdoornav_user_manual/). It integrates
+easily onto Husky and Jackal, but is compatible with third-party robots as outlined below.
+
+## Item Numbers {#item-numbers}
+
+| Description | Sales Kit |
+| :------------------------------------------ | :-------: |
+| OutdoorNav Starter Kit | 028356 |
+| OutdoorNav Starter Kit Husky Adapter Cable | 029915 |
+| OutdoorNav Starter Kit Jackal Adapter Cable | 029914 |
+| GNSS Antenna Relocation Kit | 028590 |
+| RealSense D435f Relocation Kit | 028817 |
+
+## Mechanical Mounting
+
+The OutdoorNav Starter Kit can be mounted directly using either its 80 X 80 mm or 120 X 120 mm hole pattern as shown in the following image.
+
+
+
+
+ Starter Kit mounting hole pattern
+
+
+
+On Jackal, mount the kit using the standard 120 X 120 hole pattern at the front of Jackal.
+
+On Husky, mount the kit on the leading edge of the top plate. Where a PACS-compatible top plate exists, the kit can be mounted directly.
+When using an older Husky without a PACS-compatible top plate, it will be necessary to drill your own holes.
+
+Refer also to the [OutdoorNav Starter Kit Hardware Checklist](/docs_outdoornav_user_manual/integration_requirements/hardware_integration_requirements/starter_kit_hardware_checklist).
+
+---
+
+## Electrical Integration
+
+### Power Integration
+
+The OutdoorNav Starter Kit includes a 1 m IP67 power cable to provide power from the base platform to the Starter Kit.
+Adapter cables can be used for robot-specific integrations.
+
+- For power integration on Husky, purchase the OutdoorNav Starter Kit Husky Adapter Cable, as listed in [Item Numbers](#item-numbers).
+- For power integration on Jackal, purchase the OutdoorNav Starter Kit Jackal Adapter Cable, as listed in [Item Numbers](#item-numbers).
+- For power integration on a third-party robot, an adapter cable will need to be created.
+
+ - The provided 1 m power cable is terminated with a Molex Mini-Fit Jr connector (Molex 0039012025).
+ - The adapter cable should use the appropriate mating connector (Molex 0039013029).
+ - The pinout is illustrated in the figure below:
+
+ - Pin 1: VIN (18 to 75 VDC, 7 A max)
+ - Pin 2: GND
+
+
+
+
+ Starter Kit power cable connector
+
+
+
+### Data Integration
+
+The OutdoorNav Starter Kit includes a 1 m IP67 Ethernet cable for data connectivity between the base platform to the Starter Kit.
+Refer to [OutdoorNav Platform Computer Checklist](/docs_outdoornav_user_manual/integration_requirements/platform_computer_checklist)
+for addititional details on data connectivity.
+
+---
+
+## Software Integration
+
+The required software for the OutdoorNav Starter Kit is pre-installed. However, the base platform computer must be configured as outlined
+in the [OutdoorNav Platform Computer Checklist](/docs_outdoornav_user_manual/integration_requirements/platform_computer_checklist).
diff --git a/docs/robots/accessories/add-ons/power_supplies.mdx b/docs/robots/accessories/add-ons/power_supplies.mdx
new file mode 100644
index 000000000..fc81ec6c8
--- /dev/null
+++ b/docs/robots/accessories/add-ons/power_supplies.mdx
@@ -0,0 +1,99 @@
+---
+title: Power Supplies
+sidebar_position: 7
+---
+
+import ComponentPacsExplanation from "/components/pacs_explanation_and_link.mdx";
+
+Clearpath's robots include User Power connectors with regulated 5 V, 12 V, and 24 V depending on the robot platorm.
+Refer to your robot platform's user manual for more details about these User Power connections:
+
+- [Boxer](../../indoor_robots/boxer/user_manual_boxer.mdx)
+- [Dingo](../../indoor_robots/dingo/user_manual_dingo.mdx)
+- [Husky](../../outdoor_robots/husky)
+- [Jackal](../../outdoor_robots/jackal/user_manual_jackal.mdx)
+- [Ridgeback](../../indoor_robots/ridgeback/user_manual_ridgeback.mdx)
+- [TurtleBot4](../../learning_platforms/turtlebot4.mdx)
+- [Warthog](../../outdoor_robots/warthog/user_manual_warthog.mdx)
+
+If you need more power, or at a different output voltage, you can add an enclosed DC-DC power supply.
+This is our process for choosing a new enclosed power supply.
+
+## Process For Choosing A Power Supply {#choosing_a_power_supply}
+
+1. Go to [Digi-Key](https://www.digikey.ca/en/products/filter/dc-dc-converters/132) or [Mouser](https://www.mouser.ca/c/power/dc-dc-converters/?orgKeyword=dc-dc%20converter), and search for _DC-DC Converter_
+2. Filter the results for _Active_ items.
+3. Filter for your preferred Manufacturer, such as:
+ - CUI Inc.
+ - Delta Electronics
+ - MEAN WELL
+ - Murata
+ - Traco Power
+4. Filter for your intended output voltage.
+5. Filter for your required minimum output current or power.
+6. Review the results, and find options that have an input voltage range matching your robot's battery.
+ For example, a Power Supply with an input voltage range of 18 - 36 VDC is acceptable for a Husky with a lead-acid battery, since the Husky's battery volage will be between 24 - 29 VDC.
+7. Review the allowable operating temperature range, and confirm that it is acceptable for your applicaiton.
+8. Review the Power Supply's datasheet, looking for mechanical mounting as well as shock & vibration requirements.
+
+ :::tip
+
+ 1. Consider using one of the following [PACS™ Kits](#power_supplies_pacs_kits).
+ - **15 Watt**: 028901 | Installation, Kit, Sensor—80 X 80, Power Supply, SB-15
+ - **25 Watt**: 028903 | Installation, Kit, Sensor—80 X 80, Power Supply, SB-25
+ - **150 Watt**: 028941 | Installation, Kit, Sensor—80 X 80, Power Supply, TEP 150
+ 2. There are Power Supplies that include mounting brackets for [DIN Rails](../add-ons/din_rail.mdx), which could simplify your integration.
+
+ :::
+
+9. Review the electrical termination method to see if it is ideal for your application. It is common to see screw terminals for [Ring Terminals](../../common/components/connectors/ring_terminal.mdx), though there are other options.
+
+
+
+
+ Example filtering for a 12 VDC power supply on Digi-Key
+
+
+
+
+
+We use these Relay Boards from [Numato Lab®](https://numato.com/) for controlling lights, larger relay-contactors, and similar powered devices.
+The relay board is wired to a ROS computer with a USB cable, and appears in the computer's _/dev_ directory as a serial device.
+We have developed a ROS driver using Numato's API, so we can control the relays through _rosservices_, and monitor the GPIO inputs through _rostopics_.
+
+| Description | CPR Item | Sales Kit |
+| :------------------------------ | :------: | :-------: |
+| Relay, USB controlled—2 Channel | 019464 | 029099 |
+| Relay, USB controlled—4 Channel | 019465 | 029100 |
+| Relay, USB controlled—8 Channel | 019466 | 029101 |
+
+
+
+
+
+
+ Used in a robot, for controlling a stack light, and GPIO for button inputs
+
+
+
+---
+
+## DIN Rail Kits {#relay_board_kits}
+
+:::note
+
+Refer to the [DIN Rail](../add-ons/din_rail.mdx) page for related PACS™ Kits, and item numbers of common DIN Rail lengths.
+
+:::
+
+
+
+
+
+| Description | CPR Item |
+| :-------------------------------------------------------------- | :------: |
+| PACS™ kit, including mounting, controls base, and top cap | 027220 |
+| Kit, controls base and top cap | 020711 |
+| Mounting adapter | 020710 |
+| Light Module, Green | 020714 |
+| Light Module, Red | 020715 |
+| Light Module, Amber | 020716 |
+| Light Module, Blue | 020717 |
+| Light Module, White | 020718 |
+| Light Module, Yellow | 020719 |
+| Light Module, Magenta | 020720 |
+
+## Pinout {#stack_light_pinout}
+
+| Pin | Description | Voltage |
+| :-: | :------------------------------------ | :------ |
+| COM | Ground | GND |
+| 1 | Channel 1, lowest module in the stack | +24 VDC |
+| 2 | channel 2 | +24 VDC |
+| 3 | channel 3 | +24 VDC |
+| 4 | channel 4 | +24 VDC |
+| 5 | channel 5 | +24 VDC |
+| 6 | channel 6 | +24 VDC |
+| 7 | channel 7, highest possible module | +24 VDC |
+
+---
+
+## Hardware Build
+
+### Parts List
+
+The PACS™ kit for a stack light includes:
+
+| ID | Description | CPR item | Quantity |
+| :-------: | :--------------------------------------------------------- | :-------------------------------------------------: | :------: |
+| 1 | Plate—80 X 80, Attachment Interface | [026914](/assets/pdf/clearpath_robotics_026914.pdf) | 1 |
+| 2 | Stack Light Module, Mounting Adapter—Surface Mount | 020710 | 1 |
+| 3A and 3B | Bundle, Stack Light Module, Controls Base and Top Cap | 020711 | 1 |
+| 4 | Screw, Cap, Socket Head—M4×0.7 X 16, Stainless Steel | 023128 | 2 |
+| 5 | Nut, Hex, Lock, Polymer Insert—M4×0.7 X 5, Stainless Steel | 019899 | 2 |
+| 6 | Spacer, Round—Ø5.3 X Ø8 X 7, Aluminum Alloy | 026612 | 4 |
+| 7 | Screw, Cap, Round Head—M5×0.8 X 16, Stainless Steel | 023257 | 4 |
+
+:::note
+
+Light Modules are not included in the PACS™ parts list since the configuration of modules depends on your specific integration.
+Refer to the listed Light Modules at the top of this page for common modules.
+Refer to [this catalog](/assets/pdf/clearpath_robotics_027220-TDS1.pdf) for all available modules and parts, including strobing lights, and buzzers.
+
+:::
+
+### Instructions
+
+1. Mount the Mounting Adapter (ID 2) to the attachment-plate (ID 1) using the M4 screws (ID 4) and nuts (ID 5).
+ Refer to the [attachment-plate's drawing notes](/assets/pdf/clearpath_robotics_026914.pdf) for what holes to use for mounting the stack light.
+2. Place the Controls Base (ID 3A) onto the assembly and twist 10° clockwise to lock it in place.
+3. Make and connect a cable for controlling the stack light's modules.
+ Refer to the [Pinout Section](#stack_light_pinout) above for details.
+4. Mount this assembly onto your robot, using the included spacers (ID 6) and screws (ID 7).
+5. Add light modules onto the assembly and twist 10° clockwise to lock them in place.
+ This locking connection creates an IP65 weatherproof seal, and completes the electrical connection to the Controls Base.
+6. Place the Top Cap (ID 3B) onto the assembly and twist 10° to lock it in place.
diff --git a/docs/robots/accessories/add-ons/tower.mdx b/docs/robots/accessories/add-ons/tower.mdx
new file mode 100644
index 000000000..f45fe04db
--- /dev/null
+++ b/docs/robots/accessories/add-ons/tower.mdx
@@ -0,0 +1,32 @@
+---
+title: Tower
+sidebar_position: 10
+---
+
+
+
+
+
+
+
+
+
+
+
+
+
+| Description | CPR Item | Manufacturer | Manufacturer Item |
+| :-------------------- | :------: | :---------------------- | :---------------- |
+| Spacer, Ø5.3 X Ø8 X 5 | 027005 | RAF Electronic Hardware | M0594-5-AL |
+| Standoff, 15 mm | 026991 | Wurth Elektronik | 971150581 |
+| Standoff, 35 mm | 026995 | Wurth Elektronik | 971350581 |
+| Standoff, 55 mm | 026999 | Wurth Elektronik | 971550581 |
+| Standoff, 75 mm | 027002 | Wurth Elektronik | 971750581 |
+
+We use the listed standoffs to lift sensors for better viewing angles.
diff --git a/docs/robots/accessories/add-ons/usb_hub.mdx b/docs/robots/accessories/add-ons/usb_hub.mdx
new file mode 100644
index 000000000..a35b9e145
--- /dev/null
+++ b/docs/robots/accessories/add-ons/usb_hub.mdx
@@ -0,0 +1,51 @@
+---
+title: USB Hub
+sidebar_position: 11
+---
+
+## Item Numbers
+
+| Description | CPR Item |
+| :----------------------------------------------- | :------------------------------------------------------: |
+| USB 3.0 Hub, 7 port, 9 - 24 VDC | [025440](/assets/pdf/clearpath_robotics_025440-TDS1.pdf) |
+| USB 3.0 Hub, 7 port, 9 - 24 VDC, PACS™ kit | 027642 |
+
+---
+
+## Hardware Build
+
+
+
+
+ 017642 | USB 3.0 Hub, 7 port, PACS™ kit
+
+
+
+### Parts List
+
+The PACS™ kit for this sensor includes:
+
+| ID | Description | CPR item | Quantity |
+| :-: | :-------------------------------------- | :------------------------------------------------------: | :------: |
+| 1 | Kit, Attachment—80 X 80, DIN Rail | [027881](../add-ons/din_rail.mdx) | 1 |
+| 2 | USB Hub—7 Port, USB 3.0 | [025440](/assets/pdf/clearpath_robotics_025440-TDS1.pdf) | 1 |
+| 3 | Spacer, DIN rail, Locking—35 X 7.5 X 10 | 023649 | 2 |
+
+### Instructions, 5 Port
+
+1. Build the DIN rail assembly. The instructions are listed on the [DIN Rail page](../add-ons/din_rail.mdx)
+2. Mount this assembly onto your robot, using the DIN Rail kit's included spacers and screws.
+3. Remove the USB Hub from its packaging.
+ Connect its included DIN Rail bracket to the USB Hub.
+4. Connect the USB Hub assmbly onto the DIN Rail assembly.
+5. Use two DIN Spacers (ID 3) to hold the USB Hub on the DIN Rail.
+6. Make a power cable using the green terminal block connector that was included with the USB Hub.
+ There is white lettering on the side of the USB Hub designating +V and -V terminals.
+7. Make sure the robot is off.
+ Connect the sensor's cable to the USB Hub, and to the related User Power terminal on the robot:
+ - +12 V regulated
+ - +12 V unregulated VBAT
+ - +24 V regulated
diff --git a/docs/robots/accessories/add-ons/wireless_stop_system.mdx b/docs/robots/accessories/add-ons/wireless_stop_system.mdx
new file mode 100644
index 000000000..b511cc27e
--- /dev/null
+++ b/docs/robots/accessories/add-ons/wireless_stop_system.mdx
@@ -0,0 +1,89 @@
+---
+title: Wireless Stop System
+sidebar_position: 12
+---
+
+
+
+### Parts List, Kar-Tech
+
+| ID | Description | CPR Item |
+| :-: | :--------------------------------------------------------- | :-------------------------------------------------: |
+| 1 | Plate—80 X 80, Attachment Interface, Large | [026964](/assets/pdf/clearpath_robotics_026964.pdf) |
+| 2 | Bundle, Wireless Safety Controller—Kartech | 014663 |
+| 3 | Screw, Cap, Round Head—M4×0.7 X 12, Stainless Steel | 023310 |
+| 4 | Nut, Hex, Lock, Polymer Insert—M4×0.7 X 5, Stainless Steel | 019899 |
+| 5 | Spacer, Round—Ø5.3 X Ø8 X 7, Aluminum Alloy | 026612 |
+| 6 | Screw, Cap, Round Head—M5×0.8 X 16, Stainless Steel | 023257 |
+
+### Instructions, Kar-Tech
+
+1. Fasten the Kar-Tech (ID 1) to the attachment-plate (ID 1) using M4 screws (ID 3) and nuts (ID 4).
+2. Mount this assembly onto your robot, using the included spacers (ID 5) and screws (ID 6).
+3. Add a connector to the Kar-Tech's cable.
+ Refer to [014663-TDS1](/assets/pdf/clearpath_robotics_014663-TDS1.pdf) for full details of the Kar-Tech component, including pinout.
+
+---
+
+## Hardware Build, FORT Robotics Mobility
+
+
+
+
+
+
+
+### Parts List, FORT Robotics Mobility
+
+| ID | Description | CPR Item | Quantity |
+| :-: | :------------------------------------------------- | :-------------------------------------------------: | :------: |
+| 1 | Plate—80 X 80, Attachment Interface, Large | [027110](/assets/pdf/clearpath_robotics_027110.pdf) | 1 |
+| 2 | Bundle, Wireless Safety Controller—FORT Robotics | 025727 | 1 |
+| 3 | Antenna 2.4 GHz | 007198 | 1 |
+| 4 | Screw, Cap, Flat Head—M4×0.7 X 10, Stainless Steel | 023455 | 4 |
+| 5 | Screw, Cap, Flat Head—M5×0.8 X 12, Stainless Steel | 023471 | 4 |
+
+### Instructions, FORT Robotics Mobility
+
+1. Fasten the attachment-plate (ID 1) to the robot using M5 screws (ID 5)
+2. Mount the FORT Robotics component (ID 2) to the attachment-plate (ID 1) using four M4×0.7 screws (ID 4).
+3. Attach the antenna (ID 3) to the FORT (ID 2).
+4. Add a connector to the cable included in the FOR bundle (ID 2).
+ Clearpath drawing [025657](/assets/pdf/clearpath_robotics_025657.pdf) shows an example configuration.
+ Refer to [015584-TDS2](/assets/pdf/clearpath_robotics_015584-TDS2.pdf) for full details of the FORT component, including pinout.
+5. Connect the cable you just made to the robot's User Power connector, and to your motion-stop loop control wiring.
+6. Connect a USB-mini 2.0 cable between your ROS computer and the FORT Robotics component.
+ This cable is not included in the PACS™ kit.
diff --git a/docs/robots/accessories/computers/_category_.json b/docs/robots/accessories/computers/_category_.json
new file mode 100644
index 000000000..9d253c7b2
--- /dev/null
+++ b/docs/robots/accessories/computers/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Computers",
+ "position": 2
+}
diff --git a/docs/robots/accessories/computers/computers.mdx b/docs/robots/accessories/computers/computers.mdx
new file mode 100644
index 000000000..eebd526c8
--- /dev/null
+++ b/docs/robots/accessories/computers/computers.mdx
@@ -0,0 +1,67 @@
+---
+title: Computers Overview
+sidebar_label: Computers
+sidebar_position: 1
+---
+
+
+
+
+ Jackal with a water cooled Intel i9 processor and Nvidia 1050
+
+
+
+
+
+Clearpath's robots use ROS or ROS 2, which require the robot to have a computer running an Operating System like Ubuntu.
+We mostly use Mini-ITX computers with Intel Core i3 and i7 processors, but we can run ROS on the major architectures including:
+
+- Intel Core i series
+- arm64 (Nvidia Jetson, and Raspberry Pi)
+
+Clearpath Robotics has preconfigured _Standard_ and _Performance_ computer kits for our robots, but we can make a custom computer to meet your project's requirements.
+
+## Computer Selection Considerations
+
+1. Operating conditions, air temperature
+2. Operating conditions, shock & vibration
+3. Amount of compute required, CPU
+4. Amount of compute required, GPU
+5. Amount of RAM required
+6. Amount of memory storage required
+7. Speed of memory required (for applications with many cameras)
+8. Number of connected sensors, and their data rates
+9. Any software specific considerations that impact hardware:
+ - What operating system do you intend to use?
+ - Are there kernel drivers for this component?
+ - Does this software require a GPU?
+ - Does this software require a specific processor architecture?
+10. Can the selected robot power all these devices, and what will the runtime be?
+
+## Computer Selection Process
+
+1. Choose between a consumer-computer and an industrial-computer.
+ 1. Operating environment's temperature range.
+ Consumer computers are intended for an environment between 0°C - 30°C.
+ Most outdoor robots operate in summer environments with hotter ambient air, and have extra heat added to the computer through solar radiation.
+ The type of computer and cooling strategy can allow you to use the full compute capability of the computer in these environments.
+ 2. Mechanical shock & vibration in your application.
+2. Choose between an Intel or arm64 architecture.
+ 1. Amount of compute required for sensor data.
+ 2. Amount of compute required for software, such as Autonomy.
+ 3. Are you planning to run any software specific to arm64, such as tools in [Nvidia JetPack SDK](https://developer.nvidia.com/embedded/jetpack)?
+ 4. Amount of RAM required.
+ 5. Number of sensors, and types of connections, and required speeds
+ - USB 2
+ - USB 3.0 - 3.2
+ - Ethernet (100 Mbit/s, 1 Gbit/s, 10 Gbit/s)
+ - CAN, and other industrial protocols
+ - Serial (RS-232, RS-422, RS-485)
+ Some devices may be connected to the computer through Network Switches, Hubs, or USB-converters.
+ Some devices like cameras can have a large amount of data, and require a dedicated bus on the computer, so it is best to consider the whole application when choosing the computer.
+3. Amount of hard storage required, and how fast you need to write to this storage.
+ Consider what data you are collecting from sensors, and want to store for later use.
+ There can be a considerable amount of data from sensors like cameras, so write speeds may be a limiting factor depending on your computer configuration.
diff --git a/docs/robots/accessories/computers/jetson/_category_.json b/docs/robots/accessories/computers/jetson/_category_.json
new file mode 100644
index 000000000..6f92e35d9
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jetson",
+ "position": 3
+}
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/_category_.json b/docs/robots/accessories/computers/jetson/jetson_hardware/_category_.json
new file mode 100644
index 000000000..ce77a05be
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jetson Hardware",
+ "position": 1
+}
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx
new file mode 100644
index 000000000..9fce60f79
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx
@@ -0,0 +1,13 @@
+---
+title: Jetson Hardware
+sidebar_label: Jetson Hardware
+sidebar_position: 1
+---
+
+## Installation
+
+Jetson Xavier AGX, Nano, and TX2 can be installed on a variety of platforms.
+Refer to the child pages for the details of the hardware installation.
+
+See also the instructions for
+[installing the Jetson software](../jetson_software.mdx).
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/_category_.json b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/_category_.json
new file mode 100644
index 000000000..c865d2584
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jetson Nano Hardware",
+ "position": 3
+}
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_dingo.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_dingo.mdx
new file mode 100644
index 000000000..3de788cab
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_dingo.mdx
@@ -0,0 +1,59 @@
+---
+title: Jetson Nano Hardware in Dingo
+sidebar_label: Dingo
+sidebar_position: 3
+---
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Nano hardware in Dingo. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Open up Dingo
+
+Start by removing Dingo's side panels, yellow cover plates, and removing the center channel covers.
+
+
+
+
+ Dingo's center channel
+
+
+
+### Step 2: Install the Nano
+
+Dingo includes pre-threaded mounting holes for the Jetson Nano. We recommend using 20mm standoffs to raise the board.
+
+
+
+
+ Dingo's computer bay
+
+
+
+Connect the Jetson's power cable to the 5V output from Dingo's MCU.
+
+
+
+
+ A Jetson Nano installed inside Dingo
+
+
+
+The Ethernet port on the Nano will eventually need to be connected to the Ethernet port of Dingo's MCU. If you have
+a network switch installed you can connect the MCU and the Nano to the switch. Otherwise leave the MCU disconnected
+for now so that the Nano's Ethernet port can be used for downloading the software from the internet.
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_husky.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_husky.mdx
new file mode 100644
index 000000000..ba5bae33a
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_husky.mdx
@@ -0,0 +1,85 @@
+---
+title: Jetson Nano Hardware in Husky
+sidebar_label: Husky
+sidebar_position: 1
+---
+
+import ComponentHuskyComputerRemoval from "/components/husky_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Nano hardware in Husky. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the Nano
+
+:::note
+
+Custom mounting brackets are available on
+[GitHub](https://github.com/clearpathrobotics/jetson_setup/raw/melodic/models/JetsonNanoXavierHuskyMount.stl).
+
+:::
+
+1. Print off the mount from above using a 3D printer. A 0.2 mm layer thickness should be sufficient.
+
+2. Add 4X M3 stand-offs to the board mount points. A 6 mm height is recommended.
+
+
+
+
+ Installing the standoffs
+
+
+
+3. Use M3 screws to fasten the Nano to the mount.
+
+
+
+
+ Fastening the Nano to the mount
+
+
+
+4. Attach the Nano and mount to the two M3 holes opposite the platform serial connector.
+
+
+
+
+ Attaching the mount to Husky
+
+
+
+5. Re-attach the power and serial cables from the platform to the Jetson.
+
+
+
+ Attaching the cables
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_jackal.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_jackal.mdx
new file mode 100644
index 000000000..0c8358e41
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_jackal.mdx
@@ -0,0 +1,96 @@
+---
+title: Jetson Nano Hardware in Jackal
+sidebar_label: Jackal
+sidebar_position: 2
+---
+
+import ComponentJackalComputerRemoval from "/components/jackal_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Nano hardware in Jackal. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the Nano
+
+:::note
+
+Custom mounting brackets are available on
+[GitHub](https://github.com/clearpathrobotics/jetson_setup/raw/melodic/models/JetsonNanoXavierJackalMount.stl).
+
+:::
+
+1. Print off the mount from above using a 3D printer. A 0.2 mm layer thickness should be sufficient.
+
+2. Add 4X M3 stand-offs to the board mount points. A 6 mm height is recommended.
+
+
+
+
+ Installing the standoffs
+
+
+
+3. Use M3 screws to fasten the Nano to the mount.
+
+
+
+
+ Fastening the Nano to the mount
+
+
+
+4. Position the Nano with the mount over the rear two PEMs on the tray and
+ fasten with M3 screws and washers.
+
+
+
+
+ Attaching the mount to Jackal
+
+
+
+5. Make a power cable that connects to the 12 V user
+ power (Molex connector) to a barrel connector with center positive. Refer
+ to the [Jackal User Manual](../../../../../outdoor_robots/jackal/user_manual_jackal.mdx) for the
+ pinout of the user power.
+
+ :::warning
+
+ Do NOT plug this into the ITX power plug on the power distribution board.
+
+ :::
+
+
+
+
+ Adding the power connector
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/_category_.json b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/_category_.json
new file mode 100644
index 000000000..185ec242f
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jetson TX2 Hardware",
+ "position": 3
+}
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_husky.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_husky.mdx
new file mode 100644
index 000000000..f2a2f0f85
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_husky.mdx
@@ -0,0 +1,67 @@
+---
+title: Jetson TX2 Hardware in Husky
+sidebar_label: Husky
+sidebar_position: 1
+---
+
+import ComponentHuskyComputerRemoval from "/components/husky_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the TX2 hardware in Husky. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the TX2
+
+:::note
+
+Custom mounting brackets are available
+[on Github](https://github.com/clearpathrobotics/jetson_setup/raw/noetic/models/JetsonTX2HuskyMount.stl).
+
+:::
+
+1. Download and 3D print the mounts. A 0.2 mm layer thickness should be sufficient.
+
+2. Using 4X M3 bolts, attach the plates inside the Husky platform. On the plates, add 4 M3 stand-offs
+ to the board mount points. A 6 mm height is recommended.
+
+
+
+
+ Installing the mounting plates
+
+
+
+3. Once the mounts are installed, attach the TX2 onto the mounts using M3 bolts.
+
+4. Take the power cable that powered the ITX computer and plug it into the TX2. Then, attach the serial
+ communication cable to the USB port on the TX2. If you have multiple USB peripherals on the robot,
+ you may need to use a USB hub.
+
+
+
+
+ Installing the cables
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_jackal.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_jackal.mdx
new file mode 100644
index 000000000..47e7bc78f
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_jackal.mdx
@@ -0,0 +1,78 @@
+---
+title: Jetson TX2 Hardware in Jackal
+sidebar_label: Jackal
+sidebar_position: 2
+---
+
+import ComponentJackalComputerRemoval from "/components/jackal_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the TX2 hardware in Jackal. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the TX2
+
+1. Install the Jetson TX2 using M3 screws or the screws removed from the computer. The holes
+ will only line up in one orientation.
+2. Plug a USB mini cable from the Jetson to the Jackal MCU board. This is beside where the USB
+ header was removed if you had a computer. We recommend using a USB hub to increase the number
+ of connected devices.
+
+3. Plug the power switch cable into the power switch header (J6).
+
+4. If you wish to use the antenna cables attached to the Jackal, remove the U.FL connectors from
+ the Jetson module and connect the antenna cables.
+
+ :::caution
+
+ Take your time with this step as the UF.L connectors are fragile. If you wish not to disconnect the UF.L
+ cables you can replace the antenna mounts on the Jackal with SMA extensions.
+
+ :::
+
+
+
+
+ UF.L connectors
+
+
+
+5. Make a power cable that connects to the 12 V user
+ power (Molex connector) to a barrel connector with center positive. Refer
+ to the [Jackal User Manual](../../../../../outdoor_robots/jackal/user_manual_jackal.mdx) for the
+ pinout of the user power.
+
+ :::warning
+
+ Do NOT plug this into the ITX power plug on the power distribution board.
+
+ :::
+
+
+
+
+ 12 V user power
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/_category_.json b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/_category_.json
new file mode 100644
index 000000000..3a01a438d
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jetson Xavier AGX Hardware",
+ "position": 4
+}
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_dingo.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_dingo.mdx
new file mode 100644
index 000000000..de6f7818b
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_dingo.mdx
@@ -0,0 +1,58 @@
+---
+title: Jetson Xavier AGX Hardware in Dingo
+sidebar_label: Dingo
+sidebar_position: 3
+---
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Xavier AGX hardware in Dingo. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Open up Dingo
+
+Start by removing Dingo's side panels, yellow cover plates, and removing the center channel covers.
+
+
+
+
+ Dingo's center channel
+
+
+
+### Step 2: Install the Xavier
+
+Dingo includes pre-threaded mounting holes for the Jetson Xavier. We recommend using 20 mm standoffs to raise the board.
+
+
+
+
+ Dingo's computer bay
+
+
+
+Connect the Jetson's power cable to the 12 V output from Dingo's MCU.
+
+
+
+
+
+
+
+The ethernet port on the Jetson will eventually need to be connected to the ethernet port of Dingo's MCU. If you have
+a network switch installed you can connect the MCU and the Jetson to the switch. Otherwise leave the MCU disconnected
+for now so that the Jetson's ethernet port can be used for downloading the software from the internet.
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_husky.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_husky.mdx
new file mode 100644
index 000000000..b8a6a538f
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_husky.mdx
@@ -0,0 +1,87 @@
+---
+title: Jetson Xavier AGX Hardware in Husky
+sidebar_label: Husky
+sidebar_position: 1
+---
+
+import ComponentHuskyComputerRemoval from "/components/husky_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Xavier AGX hardware in Husky. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the Xavier AGX
+
+Custom mounting brackets are available on
+[Github](https://github.com/clearpathrobotics/jetson_setup/raw/melodic/models/JetsonNanoXavierHuskyMount.stl).
+
+1. Print this mount off using a 3D printer. A 0.2 mm layer thickness should be sufficient.
+
+
+
+
+ Removing the support feet
+
+
+
+2. Use an allen wrench to remove the support feet from the bottom of the Xavier board by removing the
+ M3 bolts. Place the feet on the 3D printed mount.
+
+
+
+
+ Removing the support feet
+
+
+
+3. Attach the Xavier to the mount using four M3 x 40 screws through the bottom of the mount in the holes for Xavier.
+
+
+
+
+
+ Attaching Xavier to the mount
+
+
+
+4. Attach the Xavier and mount to the two M3 holes opposite the platform serial connector.
+
+5. Re-attach the power and serial cables from the platform to the Xavier.
+
+
+
+
+ Attaching the cables
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_jackal.mdx b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_jackal.mdx
new file mode 100644
index 000000000..9d96b0e1c
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_jackal.mdx
@@ -0,0 +1,86 @@
+---
+title: Jetson Xavier AGX Hardware in Jackal
+sidebar_label: Jackal
+sidebar_position: 2
+---
+
+import ComponentHuskyComputerRemoval from "/components/husky_remove_miniitx.mdx";
+
+## Installation
+
+:::note
+
+This page outlines the steps for installing the Xavier AGX hardware in Husky. See also
+the instructions for
+[installing the Jetson software](../../jetson_software.mdx).
+
+:::
+
+### Step 1: Remove Mini-ITX Computer
+
+:::note
+
+Skip this step if you don't have an existing computer.
+
+:::
+
+
+
+### Step 2: Install the Xavier AGX
+
+Custom mounting brackets are available on
+[Github](https://github.com/clearpathrobotics/jetson_setup/raw/melodic/models/JetsonNanoXavierJackalMount.stl).
+
+1. Print this mount off using a 3D printer. A 0.2 mm layer thickness should be sufficient.
+
+2. Use an allen wrench to remove the support feet from the bottom of the Xavier board by removing the M3 bolts.
+ Place the feet on the 3D printed mount.
+
+3. Attach the Xavier to the mount using four M3x40 screws through the bottom of the mount in the holes for Xavier.
+
+
+
+
+
+ Attaching Xavier AGX to the mount
+
+
+
+4. Position the mount with the Xavier over the rear two PEMs on the tray and fasten with M3x6 screws and washers.
+
+
+
+
+ Fasten the mount in Jackal
+
+
+
+5. Make a power cable that connects to the 12V user
+ power (Molex connector) to a barrel connector with center positive. Refer
+ to the [Jackal User Manual](../../../../../outdoor_robots/jackal/user_manual_jackal.mdx) for the
+ pinout of the user power.
+
+ :::warning
+
+ Do NOT plug this into the ITX power plug on the power distribution board.
+
+ :::
+
+
+
+
+ 12V user power
+
+
diff --git a/docs/robots/accessories/computers/jetson/jetson_software.mdx b/docs/robots/accessories/computers/jetson/jetson_software.mdx
new file mode 100644
index 000000000..360aeacdf
--- /dev/null
+++ b/docs/robots/accessories/computers/jetson/jetson_software.mdx
@@ -0,0 +1,403 @@
+---
+title: Jetson Software
+sidebar_label: Jetson Software
+sidebar_position: 3
+---
+
+## Software Installation
+
+:::note
+
+This page outlines the steps for installing the Jetson software for a Husky, Jackal, or Dingo. See also
+the instructions for installing the Jetson hardware.
+
+- Xavier AGX
+ - [Husky](jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_husky.mdx)
+ - [Jackal](jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_jackal.mdx)
+ - [Dingo](jetson_hardware/jetson_xavier_agx_hardware/jetson_xavier_agx_hardware_dingo.mdx)
+- Nano
+ - [Husky](jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_husky.mdx)
+ - [Jackal](jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_jackal.mdx)
+ - [Dingo](jetson_hardware/jetson_nano_hardware/jetson_nano_hardware_dingo.mdx)
+- TX2
+ - [Husky](jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_husky.mdx)
+ - [Jackal](jetson_hardware/jetson_tx2_hardware/jetson_tx2_hardware_jackal.mdx)
+
+:::
+
+### Step 1: Put Jetson in Recovery Mode (TX2 and Xavier AGX only)
+
+:::caution
+
+This step is not required for Jetson Nano
+
+:::
+
+Put the Jetson into recovery mode by following these steps:
+
+1. Connect the Jetson to the computer onto which SDK Manager will be installed (see next step) using the provided microUSB cable.
+2. Make sure the Jetson is powered off.
+3. Connect a monitor, mouse, and keyboard to the Jetson. (The mouse is optional, but recommended.
+ If you do not have an all-in-one mouse+keyboard you will need to use a small USB hub, as the
+ Jetson only has a single USB port.)
+4. Press and hold the REC button.
+5. Press the power button.
+
+### Step 2A: Download and Install Nvidia's SDK Manager (TX2 and Xavier AGX only)
+
+:::caution
+
+This step is not required for Jetson Nano
+
+:::
+
+1. Download the appropriate version of [Nvidia's SDK Manager](https://developer.nvidia.com/nvidia-sdk-manager)
+ onto the computer connected to the Jetson.
+
+ :::note
+
+ SDK Manager is used for installing software on the Jetson from the host computer.
+ If using Jetson TX2, only JetPack 4.x is supported and the host computer will need to have Ubuntu 16.04 or
+ Ubuntu 18.04 installed. If using Jetson Xavier Nano/AGX, JetPack 5.x is supported and the host computer will need
+ to have Ubuntu 18.04 or Ubuntu 20.04 installed.
+
+ :::
+
+2. Install the SDK Manager by running the following commands:
+
+ ```
+ cd
+ sudo dpkg -i sdkmanager__amd64.deb
+ ```
+
+ :::note
+ If your system is missing dependencies you may see error messages in the output of the `dpkg` command.
+ To resolve these, run `sudo apt-get -f install`.
+ :::
+
+3. Login the the SDK Manager using your Nvidia developer credentials.
+
+
+
+
+ Nvidia developer login
+
+
+
+4. Specify the Hardware Configuration. You do not need to setup your Host Machine unless you are planning on
+ doing Cuda work on your local computer. This can usually be disabled. Under the Target Hardware, make sure
+ to choose TX2 or Xavier AGX to match your hardware. Once complete, click "Continue to Step 02".
+
+
+
+
+ Selecting Target Hardware (TX2 shown)
+
+
+
+5. Accept the terms. Make sure the Download and Target directories are in locations that you have write-access
+ to and that your hard drive has enough space for the files. Click "Continue to Step 03".
+
+
+
+
+ Selecting Target Hardware
+
+
+
+6. Enter your sudo password and wait for the SDK manager will download the necessary files and install the image
+ on the Jetson.
+
+
+
+
+ Entering sudo password
+
+
+
+
+
+
+ Download in progress
+
+
+
+### Step 2B: Install Image on SD Card (Nano only)
+
+:::caution
+
+This step is not required for Jetson Xavier AGX or TX2
+
+:::
+
+1. Download the latest version of the
+ [Nano SD Image](https://developer.nvidia.com/jetson-nano-sd-card-image).
+
+2. Download the latest version of [Balena Etcher](https://www.balena.io/etcher/).
+
+
+
+
+ Download in progress
+
+
+
+3. Use Etcher to flash the image onto your SD card.
+
+4. Install the SD card into the Nano and power up the Nano.
+
+### Step 3: Configure the Installation
+
+1. Make sure to plug a keyboard and monitor into the Jetson. On first boot,
+ it will go through the usual Ubuntu setup steps. Accept the Licenses.
+
+
+
+
+ Accepting licenses
+
+
+
+2. Choose your language.
+
+
+
+
+ Choosing your language
+
+
+
+3. Choose your keyboard layout.
+
+
+
+
+ Choosing your keyboard layout
+
+
+
+4. Set your location.
+
+
+
+
+ Setting your location
+
+
+
+5. Specify a hostname, username, and password for the machine.
+
+ :::note
+
+ For compatibility with older versions of the Jetson software, set the username and
+ password to `nvidia`. To standardize with other Clearpath Robotics products, set the
+ username to `administrator` and the password to `clearpath`.
+
+ :::
+
+
+
+
+ Specifying your hostname, username, and password
+
+
+
+6. (**Nano only**): If prompted for a partition size, use the default size, which should fill the
+ whole SD card. Make sure it matches the maximum possible size, unless you have other plans
+ for that space.
+
+
+
+
+ Specifying partition size (Nano only)
+
+
+
+7. Wait for the installation to install the remaining standard packages.
+
+
+
+
+ Waiting for remaining packages
+
+
+
+8. Once the OS is setup, you will be brought to the desktop.
+
+
+
+
+ Post-install desktop
+
+
+
+9. Open a terminal and run `ifconfig` or `ip a` to see the IP address it is using. You will
+ need to connect it to network through wireless or ethernet.
+
+
+
+
+ Finding the IP address
+
+
+
+### Step 4: Install Extra SDK Components (TX2 and Xavier AGX only)
+
+:::caution
+
+This step is not required for Jetson Nano
+
+:::
+
+1. Back in your host computer, it will be waiting to install the extra SDK components on your Jetson.
+ Enter the username, password, and IP address you found above.
+
+
+
+
+ Installing SDK components
+
+
+
+2. The install will connenct to the remote Jetson over the network. It will continue the install
+ by transferring the files and install them.
+
+
+
+
+ Waiting for SDK component installation
+
+
+
+3. You can check the terminal window to see the progress of individual commands. This process will
+ take a while, so it can be nice to verify that the process isn't stalled.
+
+
+
+
+ Installation terminal view
+
+
+
+4. Once the process is done, you can click FINISH to close the window.
+
+
+
+
+ Installation complete
+
+
+
+### Step 5: Configure for Use with your Clearpath Robot
+
+1. Once the OS has been written to the Jetson, log into it and run the following commands to configure
+ it for use with your Clearpath robot:
+
+ ```
+ wget -c https://raw.githubusercontent.com/clearpathrobotics/ros_computer_setup/main/install.sh && bash install.sh
+ ```
+
+ :::note
+
+ If `curl` is not installed on your Jetson by default you can install it by running `sudo apt-get install curl`.
+
+ :::
+
+
+
+
+ ROS Computer Setup
+
+
+
+ These commands will download and install ROS along with the necessary `apt` packages to get your robot up and running.
+ Depending on your network speed it may take a long time for everything to install. Reboot the Jetson after these commands
+ are done to complete the configuration.
+
+2. When the Jetson starts up again, it should be connected to the robot. To see that the robot is connected by opening a
+ terminal and executing `rostopic echo /status`. You should see a 1 Hz message containing the robot's diagnostic
+ information.
+
+ Your Jetson should now be configured to operate as the robot's main computer.
+
+### Step 6: Pair a PS4 Controller with your Clearpath Robot (Optional)
+
+:::note
+
+This step is optional.
+
+:::
+
+See instructions [here](../../../../ros/installation/controller.mdx#ps4-controller) for how to pair the PS4 controller.
+
+### Step 7: Use Offboard Computer with Jetson (Optional)
+
+:::note
+
+This step is optional.
+
+:::
+
+To use your Offboard Computer (for example laptop) with the Jetson, note the IP address of the Jetson, and install the robot-specific
+desktop packages on the Offboard Computer.
+Refer to the "Installing Offboard Computer Software" section of your robot User Manual for details.
diff --git a/docs/robots/accessories/computers/mini_itx.mdx b/docs/robots/accessories/computers/mini_itx.mdx
new file mode 100644
index 000000000..31169e695
--- /dev/null
+++ b/docs/robots/accessories/computers/mini_itx.mdx
@@ -0,0 +1,83 @@
+---
+title: Mini ITX
+sidebar_label: Mini ITX
+sidebar_position: 2
+---
+
+Mini ITX computers are the default computer option for many Clearpath robots.
+
+:::note
+
+To install and configure software on your Mini ITX computer, see
+[Robot Installation](../../../ros/installation/robot.mdx).
+
+:::
+
+:::note
+
+If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team
+at \, whether you want to use a new Clearpath Robotics platform,
+or reuse your existing vehicle.
+
+:::
+
+:::note
+
+Contact our Support team at \ if you have any questions.
+
+:::
+
+## Troubleshooting
+
+#### Computer will not turn on automatically
+
+We configure the BIOS on our robots computers to boot automatically when they receive power.
+This is typically used for servers and similar industrial computers were they need to automatically restart after a blackout.
+
+To update the BIOS:
+
+1. Connect a monitor and keyboard to the robot's computer.
+2. Turn the computer on, and immediately start pressing the _delete_ key on the robot's keyboard.
+ You should be pressing it at least 4 times per second.
+
+ :::note
+
+ _delete_ is the most common key to enter BIOS, but your computer's motherboard may require a different key to be pressed.
+ The startup screen has a note stating what key needs to be pressed, but it passes by quickly, and starts loading the Operating System.
+ You can take a video of the monitor to review the information slowly.
+
+ :::
+
+3. The monitor should show the BIOS landing page.
+ There is a setting that will start the computer automatically.
+ Unfortunately, this setting seems to change names with every motherboard.
+ It is often in the Power or CPU areas of the BIOS settings.
+4. Save and Reboot after your change the setting to have the computer start with automatic power on.
+
+#### Computer keeps reverting to old BIOS settings
+
+This is often due to a low voltage CMOS battery.
+This is a battery on the computer's motherboard that powers firmware devices, like the computer's clock when the OS is not running.
+The location will change depending on the motherboard, but the battery will look like a silver coin.
+
+To replace it:
+
+1. Shut off the robot.
+2. Use a static grounding strap, so you do not damage the computer.
+3. Use hand tools to disassemble your robot, to get access to the computer.
+4. Open the computer, so you can see the motherboard.
+5. Remove the CMOS battery from the motherboard.
+ It is usually held in a spring clip that also makes the electrical connection to the motherboard.
+ Some motherboards use a CMOS battery with a pigtail lead, but this is uncommon.
+6. Purchase and install a replacement battery that matches the manufacturer information on the old battery.
+ You may find the battery on sites like [Amazon](https://www.amazon.com/), [Digi-Key](https://www.digikey.com/), and [Octopart](https://octopart.com/).
+ Contact our Support team if you cannot find a replacement.
+7. Turn on the computer, and reenter your BIOS settings.
+
+
diff --git a/docs/robots/accessories/manipulators/_category_.json b/docs/robots/accessories/manipulators/_category_.json
new file mode 100644
index 000000000..28c62929d
--- /dev/null
+++ b/docs/robots/accessories/manipulators/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Manipulators",
+ "position": 4
+}
diff --git a/docs/robots/accessories/manipulators/flir_ptu_e46.mdx b/docs/robots/accessories/manipulators/flir_ptu_e46.mdx
new file mode 100644
index 000000000..aed57c19a
--- /dev/null
+++ b/docs/robots/accessories/manipulators/flir_ptu_e46.mdx
@@ -0,0 +1,62 @@
+---
+title: FLIR PTU E46
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :---------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| PTU E46 | [018807](/assets/pdf/clearpath_robotics_018807-TDS1.pdf) | 028873 | 028872 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :----------------- |
+| Mass, PTU | 1.4 kg |
+| Mass, Payload Maximum | 2.72 kg |
+| Voltage, Minimum | 12 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 24 V |
+| Power, Average | 6 W |
+| Data | Ethernet or RS-232 |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 5 |
+| Operating Temperature, Min | -20 °C |
+| Operating Temperature, Max | 60 °C |
+
+---
+
+## Software Bringup
+
+This sensor is not included in the Clearpath Robotics robot package.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com)
+2. [Datasheet](/assets/pdf/clearpath_robotics_018807-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_018807-TDS2.pdf)
+4. [FLIR PTU E46 Website](https://www.flir.com/products/ptu-e46/?vertical=mcs&segment=oem)
+5. [ROS webpage](https://github.com/ros-drivers/flir_ptu)
diff --git a/docs/robots/accessories/manipulators/kinova_gen3_lite.mdx b/docs/robots/accessories/manipulators/kinova_gen3_lite.mdx
new file mode 100644
index 000000000..467033bbd
--- /dev/null
+++ b/docs/robots/accessories/manipulators/kinova_gen3_lite.mdx
@@ -0,0 +1,187 @@
+---
+title: Kinova Gen3 Lite
+sidebar_position: 3
+---
+
+import KinovaGen3Lite from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_gen3_lite.mdx";
+import Kinova2FLite from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_2f_lite.mdx";
+import Support from "/components/support.mdx";
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item |
+| :-------------------------------- | :------------------------------------------------------: |
+| Kinova Gen3 lite Bundle | [022586](/assets/pdf/clearpath_robotics_022586-TDS2.pdf) |
+| Kinova Gen3 lite, PACS™ kit | 027219 |
+
+---
+
+## Specifications
+
+### Overview
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 5.4 kg |
+| Voltage, Minimum | 21 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 24 V |
+| Power, Average | 20 W |
+| Power, Peak | 100 W |
+| Data | Ethernet, 100 Mbit/s |
+| Reach | 760 mm |
+| Payload | 0.5 kg |
+| Speed | 250 mm/s |
+| Range | ±155° |
+| Ingress Protection, Solids | 2 |
+| Ingress Protection, Liquids | 2 |
+| Operating Temperature, Min | 0°C |
+| Operating Temperature, Max | 40°C |
+
+### IP addresses
+
+| Description | IP address |
+| :----------------------------------- | :----------- |
+| Default from Manufacturer, USB - USB | 192.168.1.10 |
+
+---
+
+## Hardware Build
+
+### Parts List
+
+The PACS™ kit for this sensor includes:
+
+| ID | Description | CPR Item | Quantity |
+| :-: | :-------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1 | Plate—80 X 80, Attachment Interface | [026914](/assets/pdf/clearpath_robotics_026914.pdf) | 1 |
+| 2 | Manipulator Bundle | [022586](/assets/pdf/clearpath_robotics_022586-TDS1.pdf) | 1 |
+| 3 | Screw, Cap, Round Head—M6×1 X 8, Stainless Steel | 023326 | 4 |
+| 4 | Spacer, Round—Ø5.3 X Ø8 X 7, Aluminum Alloy | 026612 | 4 |
+| 5 | Screw, Cap, Round Head—M5×0.8 X 16, Stainless Steel | 023257 | 4 |
+
+### Instructions
+
+1. Remove the Kinova arm from it's packaging.
+2. There is a _Quick Connect Mounting Knob_ on the bottom of the arm.
+ You will need to remove this to mount the arm to the PACS™ bracket.
+ Hold the _Mounting Knob's_ square body using an adjustable wrench.
+ Then use a hex key to turn the _Mounting Knob's_ screw counerclockwise.
+ Then remove the _Mounting Knob_ from the arm.
+3. Refer to the attachment-plate's (ID 1) drawing [026914](/assets/pdf/clearpath_robotics_026914.pdf).
+ The notes indicate which holes are for the Kinova arm.
+ You will need to enlarge the four holes to Ø6.3 mm with a drill.
+4. Mount the arm (ID 2) to the attachment-plate (ID 1) using four M6×1 screws (ID 3).
+5. Mount this assembly onto your robot, using the included spacers (ID 4) and screws (ID 5).
+
+---
+
+## Software Bringup
+
+### ROS 2 Configuration
+This manipulator is included in the Clearpath Robotics descriptino and robot package that is installed on all of our robots.
+This allows you to add or remove manipulator from your robot's software configuration by modying the [robot configuration yaml](../../../ros/config/yaml/manipulators.mdx).
+
+
+
+
+
+### Networking, with netplan
+
+The _Kinova Gen3 lite_ does not let you change its static IP address.
+Its address is always _192.168.1.10._ when you connect using a USB - USB cable.
+
+You will need to extend the network bridge to the _192.168.1.x_ subnet to interface with the _Kinova Gen3 lite_ arm.
+
+Open the netplan configuration file with `/etc/netplan/50-clearpath-bridge.yaml`.
+You will be adding a bridge*usb section to the file, and an additional \_192.168.1.1/24* address to the network bridge.
+Your file should look like this:
+
+```
+
+network:
+ version: 2
+ renderer: networkd
+ ethernets:
+ bridge_en:
+ dhcp4: no
+ dhcp6: no
+ match:
+ name: en*
+ bridge_eth:
+ dhcp4: no
+ dhcp6: no
+ match:
+ name: eth*
+ bridge_usb:
+ dhcp4: no
+ dhcp6: no
+ match:
+ name: usb*
+ bridges:
+ br0:
+ dhcp4: yes
+ dhcp6: no
+ interfaces: [bridge_en, bridge_eth, bridge_usb]
+ addresses:
+ - 192.168.131.1/24
+ - 192.168.1.1/24
+```
+
+Close and save the file be pressing `ctrl + x`, then typing `y`, and pressing `Enter`.
+
+Now apply your new netplan changes by running `sudo netplan apply`.
+
+You can test the netplan settings by pinging the robot's computer, and pinging the Kinova arm:
+
+```
+ping 192.168.131.1
+ping 192.168.1.10
+```
+
+:::tip
+
+If you cannot ping the computer or arm, try rebooting and replugging the Kinoca Gen3 lite arm before reviewing your installation steps.
+
+:::
+
+---
+
+## Troubleshooting
+
+#### Arm is not turning on
+
+1. Turn off the robot.
+2. Remove the Kinova's circular power connector.
+3. Turn the robot back on.
+4. Use a multimeter to check that the voltage is 24 V between:
+ - Position 2 and Position 3
+ - Position 5 and Position 8
+5. If you are not reading 24 V, then:
+ - An upstream connector may not be fully seated.
+ - A fuse may be blown.
+ - A power supply may have failed.
+
+### If the Issue Persists
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/manipulators/products/gen3-lite)
+2. [Datasheet](/assets/pdf/clearpath_robotics_022586-TDS1.pdf)
+3. [Installation Guide](/assets/pdf/clearpath_robotics_022586-TDS3.pdf)
+4. [User Manual](/assets/pdf/clearpath_robotics_022586-TDS2.pdf)
+5. [Kinova Website](https://www.kinovarobotics.com/product/gen3-lite-robots)
+6. [ROS webpage](https://github.com/Kinovarobotics/ros_kortex)
diff --git a/docs/robots/accessories/manipulators/manipulators.mdx b/docs/robots/accessories/manipulators/manipulators.mdx
new file mode 100644
index 000000000..62e08fcf2
--- /dev/null
+++ b/docs/robots/accessories/manipulators/manipulators.mdx
@@ -0,0 +1,32 @@
+---
+title: Manipulators Overview
+sidebar_label: Manipulators
+sidebar_position: 1
+---
+
+
+
+---
+
+These pages outline the hardware and software steps required to get manipulators installed on your Clearpath robot.
+This documentation should be considered a quick reference, rather than a complete technical data package from the manipulator's Original Equipment Manufacturer.
+
+Also note that we have only listed the documentation of our most commonly used manipulators.
+
+We suggest you:
+
+1. Review our documentation of the manipulators related to your robot integration.
+2. Review the related Further Reading section.
+3. If you are planning to purchase a manipulator, consider visiting our [Component Store](https://store.clearpathrobotics.com/).
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs/robots/accessories/pacs.mdx b/docs/robots/accessories/pacs.mdx
new file mode 100644
index 000000000..caee26175
--- /dev/null
+++ b/docs/robots/accessories/pacs.mdx
@@ -0,0 +1,160 @@
+---
+title: PACS™
+sidebar_label: PACS™
+sidebar_position: 5
+---
+
+import Admonition from "@theme/Admonition";
+
+
+
+
+
+ A Dingo-O with many M5×0.8 threaded holes on its full-riser. These holes are aligned with M5×0.8 mounting holes on the lower plate.
+
+
+
+
+## Overview
+
+The Platform Attachment Configuration System (PACS™) is a Clearpath Robotics standard for adding components to a robot.
+Our robots have mounting plates with a 80 mm X 80 mm grid of M5×0.8 threaded holes.
+This allows us to add sensors and attachments using adapter plates.
+The _Parts Lists_ in our [Sensors pages](sensors/sensors.mdx) include these 80 mm X 80 mm brackets.
+Some example brackets are also detailed in the [Common PACS™ Items section](#pacs_common_pacs_items_for_all_robots) below.
+
+
+
+
+ A Husky configured with many sensors and accessories using PACS™ brackets.
+
+
+
+
+
+
+
+ A Husky top plate, with PACS™ hardpoint A01 in the front-left of the robot, and G08 in the back-right
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :---------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Axis F1035-E sensor | [020068](/assets/pdf/clearpath_robotics_020068-TDS1.pdf) | 027105 | 027212 |
+| Axis F34 controller hub | [020442](/assets/pdf/clearpath_robotics_020442-TDS1.pdf) | 027634 | 027633 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :---------------------------------- | :------------------- |
+| Mass, Camera | 96 g |
+| Mass, Hub | 238 g |
+| Voltage, Minimum | PoE, 8 V |
+| Voltage, Maximum | PoE, 28 V |
+| Voltage, Sensor | PoE, 24 V |
+| Power, Average | 12.6 W |
+| Data | Ethernet, 100 Mbit/s |
+| View, Horizontal | 194° |
+| View, Vertical | 113° |
+| Ingress Protection, Solids, Camera | 6 |
+| Ingress Protection, Liquids, Camera | 7 |
+| Ingress Protection, Solids, Hub | 2 |
+| Ingress Protection, Liquids, Hub | 0 |
+| Operating Temperature, Min | 0°C |
+| Operating Temperature, Max | 40°C |
+
+---
+
+## Software Bringup
+
+This sensor is not currently included in the Clearpath Robotics robot package but may be in the future.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Datasheet, Camera](/assets/pdf/clearpath_robotics_020068-TDS1.pdf)
+2. [Datesheet, Hub](/assets/pdf/clearpath_robotics_020442-TDS1.pdf)
+3. [Dimensions, Camera](/assets/pdf/clearpath_robotics_020068-TDS2.pdf)
+4. [Dimensions, Hub](/assets/pdf/clearpath_robotics_020442-TDS2.pdf)
+5. [User Manual](/assets/pdf/clearpath_robotics_020442-TDS3.pdf)
+6. [Axis website](https://www.axis.com/products/axis-f1035-e-sensor-unit)
+7. [ROS webpage](http://wiki.ros.org/axis_camera)
diff --git a/docs/robots/accessories/sensors/cameras/axis_m5525_e.mdx b/docs/robots/accessories/sensors/cameras/axis_m5525_e.mdx
new file mode 100644
index 000000000..2961ab1cc
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/axis_m5525_e.mdx
@@ -0,0 +1,65 @@
+---
+title: Axis M5525-E
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :------------------ | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Axis M5525-E sensor | [006758](/assets/pdf/clearpath_robotics_006758-TDS1.pdf) | 027106 | 027225 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass, Camera | 1.1 kg |
+| Voltage, Minimum | PoE, 20 V |
+| Voltage, Maximum | PoE, 28 V |
+| Voltage, Sensor | PoE, 24 V |
+| Power, Average | 6.6 W |
+| Data | Ethernet, 100 Mbit/s |
+| View, Horizontal | 360° |
+| View, Vertical | 0° - 90° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 6 |
+| Operating Temperature, Min | -10°C |
+| Operating Temperature, Max | 50°C |
+
+---
+
+## Software Bringup
+
+This sensor is not currently included in the Clearpath Robotics robot package but may be in the future.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Datasheet](/assets/pdf/clearpath_robotics_006758-TDS1.pdf)
+2. [Dimensions](/assets/pdf/clearpath_robotics_006758-TDS3.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_006758-TDS2.pdf)
+4. [Axis website](https://www.axis.com/products/axis-m5525-e)
+5. [ROS webpage](http://wiki.ros.org/axis_camera)
+6. [ROS tutorial](http://wiki.ros.org/axis_camera/Tutorials/SettingUpAxisNetworkCamera)
+7. [GitHub](https://github.com/ros-drivers/axis_camera)
diff --git a/docs/robots/accessories/sensors/cameras/flir_blackfly_s.mdx b/docs/robots/accessories/sensors/cameras/flir_blackfly_s.mdx
new file mode 100644
index 000000000..f31c090e5
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/flir_blackfly_s.mdx
@@ -0,0 +1,60 @@
+---
+title: FLIR Blackfly S
+sidebar_position: 3
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/flir_blackfly.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :------------------- | :----------: | :-------: | :------------------------------: |
+| FLIR Blackfly sensor | Many options | 027118 | 027218 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :------------------------- | :--------------------------------- |
+| Mass, Camera | 53 g |
+| Voltage, Minimum | 8 V or USB |
+| Voltage, Maximum | 24 V or USB |
+| Power, Average | 4.2 W |
+| Data | GigE or USB3 |
+| Resolution | 0.4 - 24.5 MP (depending on model) |
+| Frame Rate | 15 - 552 FPS |
+| Operating Temperature, Min | 0°C |
+| Operating Temperature, Max | 50°C |
+
+---
+
+## Software Bringup
+
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the
+[robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/blackfly-s)
+2. [FLIR website](https://www.flir.ca/products/blackfly-s-gige/)
+3. [ROS webpage](http://wiki.ros.org/spinnaker_sdk_camera_driver)
diff --git a/docs/robots/accessories/sensors/cameras/flir_ladybug5p.mdx b/docs/robots/accessories/sensors/cameras/flir_ladybug5p.mdx
new file mode 100644
index 000000000..9f56a53ed
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/flir_ladybug5p.mdx
@@ -0,0 +1,70 @@
+---
+title: FLIR Ladybug5+
+sidebar_position: 4
+---
+
+import Support from "/components/support.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------- | :------: | :-------: | :------------------------------: |
+| FLIR Ladybug5+ sensor | 017245 | 028894 | 028893 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :--------------------------- |
+| Mass, Camera | 3000 g |
+| Voltage, Minimum | 12 V |
+| Voltage, Maximum | 24 V |
+| Power, Average | 13 W |
+| Data | USB 3.1 |
+| Resolution | 30 MP (5 MP X 6 sensors) |
+| Frame Rate | 30 FPS @ 8k 60 FPS @ 4k |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 5 |
+| Operating Temperature, Min | -20 °C |
+| Operating Temperature, Max | 50 °C |
+
+---
+
+## Software Bringup
+
+This sensor is not included in the Clearpath Robotics robot package.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+:::note
+
+This camera does not have an official ROS driver.
+Clearpath checks that camera's data is being received on the robot's computer by using FLIR's [Software Development Kit](https://www.flir.com/products/ladybug-sdk/)
+
+:::
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/ladybug-5p)
+2. [Datasheet](/assets/pdf/clearpath_robotics_017245-TDS1.pdf)
+3. [Datasheet](/assets/pdf/clearpath_robotics_017245-TDS2.pdf)
+4. [Dimensions](/assets/pdf/clearpath_robotics_017245-TDS4.pdf)
+5. [User Manual](/assets/pdf/clearpath_robotics_017245-TDS3.pdf)
+6. [FLIR website](https://www.flir.com/products/ladybug5plus/)
diff --git a/docs/robots/accessories/sensors/cameras/occam_omni_60.mdx b/docs/robots/accessories/sensors/cameras/occam_omni_60.mdx
new file mode 100644
index 000000000..1c23a41a2
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/occam_omni_60.mdx
@@ -0,0 +1,58 @@
+---
+title: Occam Omni 60
+sidebar_position: 5
+---
+
+import Support from "/components/support.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Occam Omni 60 sensor, colour | [019645](/assets/pdf/clearpath_robotics_019645-TDS1.pdf) | 027102 | 027211 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :----------- |
+| Mass | 377 g |
+| Voltage, Minimum | 4.75 VDC |
+| Voltage, Maximum | 5.25 V |
+| Voltage, Sensor | USB or 5 VDC |
+| Power, Average | 2 W |
+| Data | USB 3.0 |
+| View, Horizontal | 360° |
+| View, Vertical | 58° |
+| Ingress Protection, Solids | 3 |
+| Ingress Protection, Liquids | 0 |
+
+## Software Bringup
+
+This sensor is not included in the Clearpath Robotics robot package.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Dimensions](/assets/pdf/clearpath_robotics_019645-TDS2.pdf)
+2. [User Manual](/assets/pdf/clearpath_robotics_019645-TDS3.pdf)
+3. [Occam Website](http://occamvisiongroup.com/product/omni-60-omnidirectional-camera/)
+4. [ROS webpage](http://wiki.ros.org/occam_vision_group_stereo-camera#ROS_SDK)
diff --git a/docs/robots/accessories/sensors/cameras/realsense_d435.mdx b/docs/robots/accessories/sensors/cameras/realsense_d435.mdx
new file mode 100644
index 000000000..1d1fd29a2
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/realsense_d435.mdx
@@ -0,0 +1,66 @@
+---
+title: RealSense D435
+sidebar_position: 6
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/intel_realsense.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Intel RealSense D435 sensor | [017103](/assets/pdf/clearpath_robotics_017103-TDS1.pdf) | 026869 | 027208 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------ |
+| Mass | 75 g |
+| Voltage, Minimum | 4.75 V |
+| Voltage, Maximum | 5.25 V |
+| Voltage, Sensor | USB ( 5 VDC ) |
+| Power, Maximum | 3.5 W |
+| Data | USB 3.0 |
+| Range, Minimum | 0.2 m |
+| Range, Maximum | 3 m |
+| View, Horizontal | 69° at 2 m |
+| View, Vertical | 42° at 2 m |
+| Ingress Protection, Solids | 3 |
+| Ingress Protection, Liquids | 0 |
+| Operating Temperature, Min | 0 °C |
+| Operating Temperature, Max | 35 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/intel-realsense-d435)
+2. [Datasheet](/assets/pdf/clearpath_robotics_017103-TDS1.pdf)
+3. [Dimensions](/assets/pdf/clearpath_robotics_017103-TDS3.pdf)
+4. [User Manual](/assets/pdf/clearpath_robotics_017103-TDS2.pdf)
+5. [RealSense Website](https://www.intelrealsense.com/depth-camera-d435/)
+6. [ROS webpage](http://wiki.ros.org/RealSense)
diff --git a/docs/robots/accessories/sensors/cameras/stereolabs_zed_2.mdx b/docs/robots/accessories/sensors/cameras/stereolabs_zed_2.mdx
new file mode 100644
index 000000000..59404302c
--- /dev/null
+++ b/docs/robots/accessories/sensors/cameras/stereolabs_zed_2.mdx
@@ -0,0 +1,70 @@
+---
+title: Stereolabs Zed 2
+sidebar_position: 7
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/stereolabs_zed.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :------------ | :------------------------------------------------------: | :-------: | :------------------------------: |
+| ZED 2 sensor | [023611](/assets/pdf/clearpath_robotics_023611-TDS1.pdf) | 028960 | 028959 |
+| ZED 2i sensor | [025844](/assets/pdf/clearpath_robotics_025844-TDS1.pdf) | 026872 | 027210 |
+
+---
+
+## Specifications
+
+| Description | Value, ZED 2 | Value, ZED 2i |
+| :-------------------------- | :------------------- | :------------ |
+| Mass | 166 g | 166 g |
+| Voltage, Minimum | 4.75 V | 4.75 V |
+| Voltage, Maximum | 5.25 V | 5.25 V |
+| Voltage, Sensor | USB (5 VDC) | USB (5 VDC) |
+| Power, Average | 1.9 W | 1.9 W |
+| Data | USB 3.0 | USB 3.0 |
+| Range, Minimum | 0.3 m | 0.2 m |
+| Range, Maximum | 20 m | 20 m |
+| View, Horizontal | 110° | 110° |
+| View, Vertical | 70° | 70° |
+| Ingress Protection, Solids | Unknown ( assume 4 ) | 6 |
+| Ingress Protection, Liquids | Unknown ( assume 0 ) | 6 |
+| Operating Temperature, Min | -10 °C | -10 °C |
+| Operating Temperature, Max | 45 °C | 45 °C |
+
+---
+
+## Software Bringup
+
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Datasheet, ZED 2](/assets/pdf/clearpath_robotics_023611-TDS1.pdf)
+2. [Dimensions, ZED 2](/assets/pdf/clearpath_robotics_023611-TDS2.pdf)
+3. [Datasheet, ZED 2i](/assets/pdf/clearpath_robotics_025844-TDS1.pdf)
+4. [Dimensions, ZED 2i](/assets/pdf/clearpath_robotics_025844-TDS2.pdf)
+5. [Stereolabs ZED Website](https://www.stereolabs.com)
+6. [ROS webpage](http://wiki.ros.org/zed-ros-wrapper)
+7. [ROS turorial](https://www.stereolabs.com/docs/ros/)
+8. [GitHub](https://github.com/stereolabs/zed-ros-wrapper)
diff --git a/docs/robots/accessories/sensors/gps/_category_.json b/docs/robots/accessories/sensors/gps/_category_.json
new file mode 100644
index 000000000..947de28a6
--- /dev/null
+++ b/docs/robots/accessories/sensors/gps/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "GPS",
+ "position": 3
+}
diff --git a/docs/robots/accessories/sensors/gps/garmin_gps_18x.mdx b/docs/robots/accessories/sensors/gps/garmin_gps_18x.mdx
new file mode 100644
index 000000000..8df082fc1
--- /dev/null
+++ b/docs/robots/accessories/sensors/gps/garmin_gps_18x.mdx
@@ -0,0 +1,63 @@
+---
+title: Garmin GPS 18x
+sidebar_position: 1
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/garmin_18x.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Garmin GPS 18x sensor, 5 Hz | [001893](/assets/pdf/clearpath_robotics_001893-TDS1.pdf) | 028876 | 028875 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ |
+| Mass | 165 kg |
+| Voltage, Minimum | 4 V |
+| Voltage, Maximum | 5.5 V |
+| Voltage, Sensor | 5 V |
+| Power, Average | 0.5 W |
+| Data | TIA-232-F ( RS-232 ) Default setting is 19200 baud |
+| View, Vertical | Unknown |
+| Position Accuracy | 15 m |
+| Position Accuracy RTK (requires a [Base Station](../../add-ons/base_station.mdx) or a positioning-service) | Unknown |
+| Ingress Protection, Solids | Unknown ( assume 6 ) |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -30 °C |
+| Operating Temperature, Max | 80 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/gps)
+2. [User Manual](/assets/pdf/clearpath_robotics_001893-TDS1.pdf)
+3. [Swift Navigation Website](https://www.garmin.com/en-CA/p/13195)
+4. [ROS webpage](https://github.com/ros-drivers/nmea_navsat_driver)
diff --git a/docs/robots/accessories/sensors/gps/microstrain_gq7.mdx b/docs/robots/accessories/sensors/gps/microstrain_gq7.mdx
new file mode 100644
index 000000000..85207dd6b
--- /dev/null
+++ b/docs/robots/accessories/sensors/gps/microstrain_gq7.mdx
@@ -0,0 +1,121 @@
+---
+title: MicroStrain GQ7
+sidebar_position: 3
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/microstrain_gq7.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| MicroStrain GQ7 | N/A | N/A | N/A |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ |
+| Mass | 78 g |
+| Voltage, Minimum | 4.2 V |
+| Voltage, Maximum | 16 V |
+| Voltage, Sensor | 5 V or 12 V |
+| Power, Average | 2.0 W |
+| Data | USB or RS-232 Default setting is 115200 baud |
+| View, Vertical | Unknown |
+| Position Accuracy | 1.25 m horizontal 2 m vertical |
+| Position Accuracy RTK (requires a [Base Station](../../add-ons/base_station.mdx) or a positioning-service) | 2 cm |
+| Ingress Protection, Solids | 4 |
+| Ingress Protection, Liquids | None |
+| Operating Temperature, Min | -40 °C |
+| Operating Temperature, Max | 85 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+#### Antenna Offsets
+
+The GQ7 needs to have it's antenna offsets properly configured in order to get optimal position and orientation estimates. The `microstrain_inertial_driver` makes this easy to do,
+and allows multiple ways to accomplish this.
+
+##### From tf tree
+
+The `microstrain_inertial_driver` can look up the location of the antennas from the transform tree as long as it is configured to look for the correct frames.
+One can configure antenna offsets to be looked up from the transform tree by including the following parameters
+
+```yaml
+gps:
+ - model: microstrain_gq7
+ ...
+ ros_parameters:
+ microstrain_inertial_driver:
+ gnss1_antenna_offset_source : 2
+ gnss1_frame_id : "right_antenna_link"
+ gnss2_antenna_offset_source : 2
+ gnss2_frame_id : "left_antenna_link"
+```
+
+A more complete example of configuring the GQ7 to look up the locations of the antennas from the transform tree, and setting up the antennas in the robot.yaml can be found
+[here](https://github.com/clearpathrobotics/clearpath_config/tree/main/clearpath_config/sample/j100/j100_microstrain_gq7.yaml)
+
+##### Manually
+
+This method is not recommended for use with clearpath robots as the `robot.yaml` makes it easy to define GNSS antennas in your robot description, but it is the quickest way to get started.
+One can configure antenna offsets manually by including the following parameters:
+
+**IMPORTANT**: When manually configuring the antenna offsets, the measurements will be in the MicroStrain vehicle frame. See
+[this wiki page](https://wiki.ros.org/microstrain_inertial_driver/use_enu_frame#different_frames) for more information.
+
+```yaml
+gps:
+ - model: microstrain_gq7
+ ...
+ ros_parameters:
+ microstrain_inertial_driver:
+ gnss1_antenna_offset_source : 1
+ gnss1_antenna_offset : [0.0, 0.7, -1.0] # x, y, z in meters
+ gnss2_antenna_offset_source : 1
+ gnss2_antenna_offset : [0.0, -0.7, -1.0] # x, y, z in meters
+```
+
+#### Transforms
+
+In order to integrate more easily with existing ROS tools such as RViz and Nav2, the `microstrain_inertial_driver` will publish several transforms.
+
+The default behavior of the device when used in a clearpath robot is to publish the global position of the `odom` frame relative to the first valid fix received by the device,
+but it can be configured to publish the global position of a different frame, or no frames at all.
+For more information on the transforms published and how to configure them, see the [transforms](https://wiki.ros.org/microstrain_inertial_driver/transforms)
+page of the `microstrain_inertial_driver` wiki.
+
+
+---
+
+## Troubleshooting
+
+
+
+For issues directly related to the `microstrain_inertial_driver` or the GQ7, please open an issue on [GitHub](https://github.com/LORD-MicroStrain/microstrain_inertial/issues/new/choose)
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/gnss-ins)
+2. [GQ7 User Manual](https://files.microstrain.com/GQ7+User+Manual/Home.htm)
+3. [GQ7 Webpage](https://www.microstrain.com/inertial-sensors/3dm-gq7)
+4. [microstrain_inertial_driver wiki](https://wiki.ros.org/microstrain_inertial_driver)
+5. [microstrain_inertial_description wiki](https://wiki.ros.org/microstrain_inertial_description)
diff --git a/docs/robots/accessories/sensors/gps/swift_navigation_duro.mdx b/docs/robots/accessories/sensors/gps/swift_navigation_duro.mdx
new file mode 100644
index 000000000..8577634af
--- /dev/null
+++ b/docs/robots/accessories/sensors/gps/swift_navigation_duro.mdx
@@ -0,0 +1,65 @@
+---
+title: Swift Navigation Duro
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/swiftnav_duro.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :------------------------------------ | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Swift Navigation Duro sensor | [015822](/assets/pdf/clearpath_robotics_015822-TDS1.pdf) | 027107 | 027213 |
+| Swift Navigation Duro inertial sensor | 018151 | 027108 | 027214 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :--------------------------------------------------------------------------------------------------------- | :------------------- |
+| Mass | 0.8 kg |
+| Voltage, Minimum | 10 V |
+| Voltage, Maximum | 35 V |
+| Voltage, Sensor | 12 V or 24 V |
+| Power, Average | 5 W |
+| Data | Ethernet, 100 Mbit/s |
+| View, Vertical | ±60° from vertical |
+| Position Accuracy | 2.5 m |
+| Position Accuracy RTK (requires a [Base Station](../../add-ons/base_station.mdx) or a positioning-service) | 0.01 m |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -40 °C |
+| Operating Temperature, Max | 75 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/gps/products/duro)
+2. [Datasheet](/assets/pdf/clearpath_robotics_015822-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_015822-TDS2.pdf)
+4. [Swift Navigation Website](https://www.swiftnav.com/duro)
+5. [ROS webpage](http://wiki.ros.org/swiftnav_ros)
diff --git a/docs/robots/accessories/sensors/imu/_category_.json b/docs/robots/accessories/sensors/imu/_category_.json
new file mode 100644
index 000000000..087a345d3
--- /dev/null
+++ b/docs/robots/accessories/sensors/imu/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "IMU",
+ "position": 4
+}
diff --git a/docs/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx b/docs/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx
new file mode 100644
index 000000000..419a38903
--- /dev/null
+++ b/docs/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx
@@ -0,0 +1,77 @@
+---
+title: MicroStrain 3DM-GX5
+sidebar_position: 1
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/microstrain_imu.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :---------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Microstrain 3DM-GX5-10 sensor | [017839](/assets/pdf/clearpath_robotics_017839-TDS1.pdf) | 028963 | 028962 |
+| Microstrain 3DM-GX5-15 sensor | [017772](/assets/pdf/clearpath_robotics_017772-TDS1.pdf) | 027114 | 027215 |
+| Microstrain 3DM-GX5-25 sensor | [014603](/assets/pdf/clearpath_robotics_014603-TDS1.pdf) | 027117 | 027217 |
+| Microstrain 3DM-GX5-35 sensor | [028528](/assets/pdf/clearpath_robotics_028528-TDS1.pdf) | 028964 | 028957 |
+| Microstrain 3DM-GX5-45 sensor | [017391](/assets/pdf/clearpath_robotics_017391-TDS2.pdf) | 028966 | 028965 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :---------------- |
+| Mass | 16.5 - 20 g |
+| Voltage, Minimum | 4 V, or USB |
+| Voltage, Maximum | 36 V, or USB |
+| Power, Maximum | 0.3 - 0.8 W |
+| Data | USB 2.0 or RS-232 |
+| Ingress Protection, Solids | 3 |
+| Ingress Protection, Liquids | 0 |
+| Operating Temperature, Min | -40 °C |
+| Operating Temperature, Max | 85 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store, 3DM-GX5-10](https://store.clearpathrobotics.com/collections/orientation/products/3dm-gx5-10)
+2. [Clearpath Robotics Store, 3DM-GX5-15](https://store.clearpathrobotics.com/collections/vru/products/3dm-gx5-15)
+3. [Clearpath Robotics Store, 3DM-GX5-25](https://store.clearpathrobotics.com/collections/ahrs/products/3dm-gx5-25)
+4. [Clearpath Robotics Store, 3DM-GX5-35](https://store.clearpathrobotics.com/collections/ahrs/products/3dm-gx5-35)
+5. [Clearpath Robotics Store, 3DM-GX5-45](https://store.clearpathrobotics.com/collections/gnss-ins/products/3dm-gx5-45)
+6. [Datasheet, 3DM-GX5-10](/assets/pdf/clearpath_robotics_017839-TDS1.pdf)
+7. [Datasheet, 3DM-GX5-15](/assets/pdf/clearpath_robotics_017772-TDS1.pdf)
+8. [Datasheet, 3DM-GX5-25](/assets/pdf/clearpath_robotics_014603-TDS1.pdf)
+9. [Datasheet, 3DM-GX5-35](/assets/pdf/clearpath_robotics_028528-TDS1.pdf)
+10. [Datasheet, 3DM-GX5-45](/assets/pdf/clearpath_robotics_017391-TDS1.pdf)
+11. [User Manual, 3DM-GX5-10](/assets/pdf/clearpath_robotics_017839-TDS2.pdf)
+12. [User Manual, 3DM-GX5-15](/assets/pdf/clearpath_robotics_017772-TDS2.pdf)
+13. [User Manual, 3DM-GX5-25](/assets/pdf/clearpath_robotics_014603-TDS2.pdf)
+14. [User Manual, 3DM-GX5-35](/assets/pdf/clearpath_robotics_028528-TDS2.pdf)
+15. [User Manual, 3DM-GX5-45](/assets/pdf/clearpath_robotics_017391-TDS2.pdf)
+16. [LORD MicroStrain Website](https://www.microstrain.com/inertial-sensors/g-series)
+17. [ROS webpage](http://wiki.ros.org/microstrain_inertial_driver)
+18. [GitHub](https://github.com/LORD-MicroStrain/microstrain_inertial)
diff --git a/docs/robots/accessories/sensors/imu/redshift_labs_um7.mdx b/docs/robots/accessories/sensors/imu/redshift_labs_um7.mdx
new file mode 100644
index 000000000..8a2c09d32
--- /dev/null
+++ b/docs/robots/accessories/sensors/imu/redshift_labs_um7.mdx
@@ -0,0 +1,60 @@
+---
+title: Redshift Labs UM7
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/redshift_um7.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :----------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Redshift Labs UM7 sensor | [011914](/assets/pdf/clearpath_robotics_011914-TDS1.pdf) | 028881 | 028880 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :-------------------------------------------------- |
+| Mass | 11 g |
+| Voltage, Minimum | 4 V |
+| Voltage, Maximum | 5.5 V |
+| Voltage, Sensor | 5 V |
+| Power, Average | 0.25 W |
+| Data | UART ( RS-232 ) Default setting is 115200 baud |
+| Ingress Protection, Solids | Unknown ( assume 4 ) |
+| Ingress Protection, Liquids | Unknown ( assume 0 ) |
+| Operating Temperature, Min | -40 °C |
+| Operating Temperature, Max | 85 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/orientation)
+2. [User Manual](/assets/pdf/clearpath_robotics_011914-TDS1.pdf)
+3. [Redshift Labs UM7 Website](https://redshiftlabs.com.au/product/um7-orientation-sensor/)
+4. [ROS webpage](https://github.com/ros-drivers/um7)
diff --git a/docs/robots/accessories/sensors/lidar_2d/_category_.json b/docs/robots/accessories/sensors/lidar_2d/_category_.json
new file mode 100644
index 000000000..83f246104
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_2d/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "2D Lidar",
+ "position": 5
+}
diff --git a/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx
new file mode 100644
index 000000000..4e68eea61
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx
@@ -0,0 +1,67 @@
+---
+title: Hokuyo UST10-LX
+sidebar_position: 1
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :------------------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Hokuyo UST10-LX | [011759](/assets/pdf/clearpath_robotics_011759-TDS1.pdf) | 027207 | 026611 |
+| Hokuyo UST10-LX, 90° vertical mounting | [011759](/assets/pdf/clearpath_robotics_011759-TDS1.pdf) | 026966 | 027224 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 0.13 kg |
+| Voltage, Minimum | 10 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 12 V or 24 V |
+| Power, Average | 3.6 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.06 m |
+| Range, Maximum | 10 m |
+| Range, Accuracy | ± 40 mm |
+| View, Horizontal | 270 ° |
+| Resolution, Horizontal | 0.25 ° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 5 |
+| Operating Temperature, Min | -10 °C |
+| Operating Temperature, Max | 50 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/2dlidar/products/hokuyo-ust-10lx)
+2. [Datasheet](/assets/pdf/clearpath_robotics_011759-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_011759-TDS2.pdf)
+4. [Hokuyo Website](https://www.hokuyo-aut.jp/search/single.php?serial=167#download)
+5. [ROS webpage](http://wiki.ros.org/urg_node)
diff --git a/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx
new file mode 100644
index 000000000..0101ec519
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx
@@ -0,0 +1,66 @@
+---
+title: Hokuyo UST20-LX
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Hokuyo UST20-LX sensor | [016359](/assets/pdf/clearpath_robotics_016359-TDS1.pdf) | 029013 | 029012 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 0.13 kg |
+| Voltage, Minimum | 10 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 12 V or 24 V |
+| Power, Average | 3.6 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.06 m |
+| Range, Maximum | 20 m |
+| Range, Accuracy | ± 40 mm |
+| View, Horizontal | 270 ° |
+| Resolution, Horizontal | 0.25 ° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 5 |
+| Operating Temperature, Min | -10 °C |
+| Operating Temperature, Max | 50 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/2dlidar/products/hokuyo-ust-20lx)
+2. [Datasheet](/assets/pdf/clearpath_robotics_016359-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_016359-TDS2.pdf)
+4. [Hokuyo Website](https://www.hokuyo-aut.jp/search/single.php?serial=167#download)
+5. [ROS webpage](http://wiki.ros.org/urg_node)
diff --git a/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx
new file mode 100644
index 000000000..19326cc91
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx
@@ -0,0 +1,64 @@
+---
+title: Hokuyo UST30-LX
+sidebar_position: 3
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Hokuyo UST30-LX sensor | [027584](/assets/pdf/clearpath_robotics_027584-TDS1.pdf) | 029015 | 029014 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 0.13 kg |
+| Voltage, Minimum | 10 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 12 V or 24 V |
+| Power, Average | 3.6 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.06 m |
+| Range, Maximum | 30 m |
+| Range, Accuracy | ± 40 mm |
+| View, Horizontal | 270 ° |
+| Resolution, Horizontal | 0.25 ° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -30 °C |
+| Operating Temperature, Max | 50 °C |
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/2dlidar)
+2. [Datasheet](/assets/pdf/clearpath_robotics_027584-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_027584-TDS2.pdf)
+4. [Hokuyo Website](https://www.hokuyo-aut.jp/search/single.php?serial=233#download)
+5. [ROS webpage](http://wiki.ros.org/urg_node)
diff --git a/docs/robots/accessories/sensors/lidar_2d/sick_lms111.mdx b/docs/robots/accessories/sensors/lidar_2d/sick_lms111.mdx
new file mode 100644
index 000000000..99488181b
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_2d/sick_lms111.mdx
@@ -0,0 +1,64 @@
+---
+title: SICK LMS-111
+sidebar_position: 4
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/sick_lms1xx.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :----------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| SICK LMS111-10100 sensor | [006387](/assets/pdf/clearpath_robotics_006387-TDS1.pdf) | 027657 | 027656 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :------------------------- | :------------------- |
+| Mass | 1.1 kg |
+| Voltage, Minimum | 10.8 V |
+| Voltage, Maximum | 30 V |
+| Voltage, Sensor | 24 V |
+| Power, Average | 8 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.5 m |
+| Range, Maximum | 20 m |
+| Range, Accuracy | ±3 cm |
+| View, Horizontal | 270 ° |
+| Resolution, Horizontal | 0.25 ° |
+| Operating Temperature, Min | -30 °C |
+| Operating Temperature, Max | 50 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/2dlidar/products/lms111)
+2. [Datasheet](/assets/pdf/clearpath_robotics_006387-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_006387-TDS2.pdf)
+4. [SICK website](https://www.sick.com/ca/en/detection-and-ranging-solutions/2d-lidar-sensors/lms1xx/lms111-10100/p/p109842)
+5. [ROS webpage](http://wiki.ros.org/LMS1xx)
diff --git a/docs/robots/accessories/sensors/lidar_3d/_category_.json b/docs/robots/accessories/sensors/lidar_3d/_category_.json
new file mode 100644
index 000000000..ffc1a94b7
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "3D Lidar",
+ "position": 6
+}
diff --git a/docs/robots/accessories/sensors/lidar_3d/ouster.mdx b/docs/robots/accessories/sensors/lidar_3d/ouster.mdx
new file mode 100644
index 000000000..6cfeac49b
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/ouster.mdx
@@ -0,0 +1,85 @@
+---
+title: Ouster
+sidebar_position: 5
+---
+
+import Support from "/components/support.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :---------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Sensor, Ouster OS0-32, gen 7 | | | |
+| Sensor, Ouster OS0-64, gen 7 | [028738](/assets/pdf/clearpath_robotics_028738-TDS1.pdf) | 028661 | 028851 |
+| Sensor, Ouster OS0-128, gen 7 | [028740](/assets/pdf/clearpath_robotics_028740-TDS1.pdf) | 028662 | 028852 |
+| Sensor, Ouster OS1-32, gen 7 | [028848](/assets/pdf/clearpath_robotics_028848-TDS1.pdf) | 028663 | 028853 |
+| Sensor, Ouster OS1-64, gen 7 | [028742](/assets/pdf/clearpath_robotics_028742-TDS1.pdf) | 028664 | 028854 |
+| Sensor, Ouster OS1-128, gen 7 | [028745](/assets/pdf/clearpath_robotics_028745-TDS1.pdf) | 028665 | 028855 |
+| Sensor, Ouster OS2-32, gen 7 | [028849](/assets/pdf/clearpath_robotics_028849-TDS1.pdf) | 028666 | 028856 |
+| Sensor, Ouster OS2-64, gen 7 | [028747](/assets/pdf/clearpath_robotics_028747-TDS1.pdf) | 028667 | 028857 |
+| Sensor, Ouster OS2-128, gen 7 | [028749](/assets/pdf/clearpath_robotics_028749-TDS1.pdf) | 028668 | 028858 |
+
+---
+
+## Specifications
+
+| Description | Value, OS0 | Value, OS1 | Value, OS2 |
+| :--------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Mass | 447 g | 447 g | 1100 g |
+| Voltage, Minimum | 9 V | 9 V | 9 V |
+| Voltage, Maximum | 34 V | 34 V | 34 V |
+| Voltage, Sensor | 12 V or 24 V | 12 V or 24 V | 12 V or 24 V |
+| Power, Average | 17 W | 17 W | 21 W |
+| Data |
**OS0-32** Ethernet, 65.6 Mbit/s
**OS0-64** Ethernet, 128.5 Mbit/s
**OS0-128** Ethernet 254.3 Mbit/s
|
**OS0-32** Ethernet, 65.6 Mbit/s
**OS0-64** Ethernet, 128.5 Mbit/s
**OS0-128** Ethernet 254.3 Mbit/s
|
**OS0-32** Ethernet, 65.6 Mbit/s
**OS0-64** Ethernet, 128.5 Mbit/s
**OS0-128** Ethernet 254.3 Mbit/s
|
+| Range, Minimum | 0.3 m | 0.3 m | 1.0 m |
+| Range, Maximum ( 10% reflectivity) | 15 m | 45 m | 80 m |
+| Range, Maximum ( 80% reflectivity) | 45 m | 100 m | 210 m |
+| Range, Accuracy | ± 3 cm | ± 3 cm | ± 3 cm |
+| View, Horizontal | 360° | 360° | 360° |
+| View, Vertical | ± 45° | ± 22.5° | ± 11.25° |
+| Resolution, Horizontal | Configurable
0.7°
0.35°
0.18°
| Configurable
0.7°
0.35°
0.18°
| Configurable
0.7°
0.35°
0.18°
|
+| Resolution, Vertical |
**OS0-32** 2.8°
**OS0-64** 1.4°
**OS0-128** 0.7°
|
**OS0-32** 1.4°
**OS0-64** 0.7°
**OS0-128** 0.35°
|
**OS0-32** 0.7°
**OS0-64** 0.35°
**OS0-128** 0.18°
|
+| Ingress Protection, Solids | 6 | 6 | 6 |
+| Ingress Protection, Liquids | 8 | 8 | 8 |
+| Operating Temperature, Min | -40 °C | -40 °C | -20 °C |
+| Operating Temperature, Max | 60 °C | 60 °C | 60 °C |
+
+---
+
+## Software Bringup
+
+This sensor is not included in the Clearpath Robotics robot package.
+If you purchased this sensor with your Clearpath robot, we will install the necessary ROS packages and configuration details on the robot's computer.
+
+Refer to this page's Further Reading section for more details.
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/3d-lidar)
+2. [OS0, Datasheet](/assets/pdf/clearpath_robotics_028738-TDS1.pdf)
+3. [OS0, Manual](/assets/pdf/clearpath_robotics_028738-TDS2.pdf)
+4. [OS0, Drawing](/assets/pdf/clearpath_robotics_028738-TDS3.pdf)
+5. [OS1, Datasheet](/assets/pdf/clearpath_robotics_028848-TDS1.pdf)
+6. [OS1, Manual](/assets/pdf/clearpath_robotics_028848-TDS2.pdf)
+7. [OS1, Drawing](/assets/pdf/clearpath_robotics_028848-TDS3.pdf)
+8. [OS2, Datasheet](/assets/pdf/clearpath_robotics_028849-TDS1.pdf)
+9. [OS2, Manual](/assets/pdf/clearpath_robotics_028849-TDS2.pdf)
+10. [OS2, Drawing](/assets/pdf/clearpath_robotics_028849-TDS3.pdf)
+11. [Ouster website](https://ouster.com/)
+12. [ROS GitHub](https://github.com/ouster-lidar/ouster-ros)
+13. [ROS tutorial](https://static.ouster.dev/sdk-docs/ros/index.html)
diff --git a/docs/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx
new file mode 100644
index 000000000..f0f02177e
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx
@@ -0,0 +1,74 @@
+---
+title: Velodyne Hi-Res
+sidebar_position: 3
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Velodyne Puck sensor | [013688](/assets/pdf/clearpath_robotics_029029-TDS1.pdf) | — | — |
+| Velodyne Puck sensor, with M12 connector | [029029](/assets/pdf/clearpath_robotics_029029-TDS1.pdf) | 029032 | 029031 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 830 g |
+| Voltage, Minimum | 9 V |
+| Voltage, Maximum | 18 V |
+| Voltage, Sensor | 12 V |
+| Power, Average | 8 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.9 m |
+| Range, Maximum | 100 m |
+| Range, Accuracy | ±3 cm |
+| View, Horizontal | 360° |
+| View, Vertical | ±10° |
+| Resolution, Horizontal | 0.4° |
+| Resolution, Vertical | 1.33° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -10 °C |
+| Operating Temperature, Max | 60 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/3d-lidar/products/puck-hi-res)
+2. [Datasheet](/assets/pdf/clearpath_robotics_029029-TDS1.pdf)
+3. [User Manual, Sensor](/assets/pdf/clearpath_robotics_029029-TDS2.pdf)
+4. [User Manual, Control Box](/assets/pdf/clearpath_robotics_029029-TDS3.pdf)
+5. [Drawing, Sensor](/assets/pdf/clearpath_robotics_029029-TDS4.pdf)
+6. [Drawing, Control Box](/assets/pdf/clearpath_robotics_029029-TDS6.pdf)
+7. [Wiring, Contol Box](/assets/pdf/clearpath_robotics_029029-TDS5.pdf)
+8. [Velodyne website](https://velodynelidar.com/products/puck-hi-res/)
+9. [ROS webpage](http://wiki.ros.org/velodyne)
+10. [ROS tutorial](http://wiki.ros.org/velodyne/Tutorials/Getting%20Started%20with%20the%20Velodyne%20VLP16)
diff --git a/docs/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx
new file mode 100644
index 000000000..2f271b191
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx
@@ -0,0 +1,71 @@
+---
+title: Velodyne Puck
+sidebar_position: 2
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------------------------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Velodyne Puck sensor | [011703](/assets/pdf/clearpath_robotics_011703-TDS2.pdf) | — | — |
+| Velodyne Puck sensor, with M12 connector | [020972](/assets/pdf/clearpath_robotics_020972-TDS2.pdf) | 026859 | 027206 |
+| Velodyne Puck sensor, with M12 connector, 90° vertical mounting | [020972](/assets/pdf/clearpath_robotics_020972-TDS2.pdf) | 026965 | 027222 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 830 g |
+| Voltage, Minimum | 9 V |
+| Voltage, Maximum | 18 V |
+| Voltage, Sensor | 12 V |
+| Power, Average | 8 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.9 m |
+| Range, Maximum | 100 m |
+| Range, Accuracy | ±3 cm |
+| View, Horizontal | 360° |
+| View, Vertical | ±15° |
+| Resolution, Horizontal | 0.4° |
+| Resolution, Vertical | 2° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -10 °C |
+| Operating Temperature, Max | 60 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/3d-lidar/products/puck)
+2. [Datasheet](/assets/pdf/clearpath_robotics_011703-TDS2.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_011703-TDS1.pdf)
+4. [Velodyne website](https://store.clearpathrobotics.com/collections/3d-lidar/products/puck)
+5. [ROS webpage](http://wiki.ros.org/velodyne)
+6. [ROS tutorial](http://wiki.ros.org/velodyne/Tutorials/Getting%20Started%20with%20the%20Velodyne%20VLP16)
diff --git a/docs/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx
new file mode 100644
index 000000000..fe70bfab3
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx
@@ -0,0 +1,72 @@
+---
+title: Velodyne Puck Lite
+sidebar_position: 1
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Velodyne Puck Lite sensor | [016312](/assets/pdf/clearpath_robotics_023729-TDS1.pdf) | — | — |
+| Velodyne Puck Lite sensor, with M12 connector | [023729](/assets/pdf/clearpath_robotics_023729-TDS1.pdf) | 029027 | 029026 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :------------------------- | :------------------- |
+| Mass | 590 g |
+| Voltage, Minimum | 9 V |
+| Voltage, Maximum | 18 V |
+| Voltage, Sensor | 12 V |
+| Power, Average | 8 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.9 m |
+| Range, Maximum | 100 m |
+| Range, Accuracy | ±3 cm |
+| View, Horizontal | 360° |
+| View, Vertical | ±15° |
+| Resolution, Horizontal | 0.4° |
+| Resolution, Vertical | 2° |
+| Operating Temperature, Min | -10 °C |
+| Operating Temperature, Max | 60 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/3d-lidar/products/puck-lite)
+2. [Datasheet](/assets/pdf/clearpath_robotics_023729-TDS1.pdf)
+3. [User Manual, Sensor](/assets/pdf/clearpath_robotics_023729-TDS2.pdf)
+4. [User Manual, Control Box](/assets/pdf/clearpath_robotics_023729-TDS3.pdf)
+5. [Drawing, Sensor](/assets/pdf/clearpath_robotics_023729-TDS4.pdf)
+6. [Drawing, Control Box](/assets/pdf/clearpath_robotics_023729-TDS6.pdf)
+7. [Wiring, Contol Box](/assets/pdf/clearpath_robotics_023729-TDS5.pdf)
+8. [Velodyne website](https://velodynelidar.com/products/puck-lite/)
+9. [ROS webpage](http://wiki.ros.org/velodyne)
+10. [ROS tutorial](http://wiki.ros.org/velodyne/Tutorials/Getting%20Started%20with%20the%20Velodyne%20VLP16)
diff --git a/docs/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx b/docs/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx
new file mode 100644
index 000000000..99f2a5978
--- /dev/null
+++ b/docs/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx
@@ -0,0 +1,71 @@
+---
+title: Velodyne Ultra Puck
+sidebar_position: 4
+---
+
+import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+
+
+
+
+## Item Numbers
+
+| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
+| Velodyne Ultra Puck sensor | [016901](/assets/pdf/clearpath_robotics_029035-TDS1.pdf) | — | — |
+| Velodyne Ultra Puck sensor, with M12 connector | [029035](/assets/pdf/clearpath_robotics_029035-TDS1.pdf) | 029037 | 029036 |
+
+---
+
+## Specifications
+
+| Description | Value |
+| :-------------------------- | :------------------- |
+| Mass | 925 g |
+| Voltage, Minimum | 10.5 V |
+| Voltage, Maximum | 18 V |
+| Voltage, Sensor | 12 V |
+| Power, Average | 10 W |
+| Data | Ethernet, 100 Mbit/s |
+| Range, Minimum | 0.9 m |
+| Range, Maximum | 200 m |
+| Range, Accuracy | ±3 cm |
+| View, Horizontal | 360° |
+| View, Vertical | -25° to +15° |
+| Resolution, Horizontal | 0.4° |
+| Resolution, Vertical | 0.33° |
+| Ingress Protection, Solids | 6 |
+| Ingress Protection, Liquids | 7 |
+| Operating Temperature, Min | -20 °C |
+| Operating Temperature, Max | 60 °C |
+
+---
+
+## Software Bringup
+This sensor is included in the Clearpath Robotics robot package that is installed on all of our robots.
+This allows you to add or remove the sensor from your robot's software description by modifying the [robot configuration yaml](../../../../ros/config/yaml/sensors/overview.mdx).
+
+
+
+---
+
+## Troubleshooting
+
+
+
+---
+
+## Further Reading
+
+1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/3d-lidar/products/ultra-puck)
+2. [Datasheet](/assets/pdf/clearpath_robotics_029035-TDS1.pdf)
+3. [User Manual](/assets/pdf/clearpath_robotics_029035-TDS2.pdf)
+4. [Drawing, Sensor](/assets/pdf/clearpath_robotics_029035-TDS3.pdf)
+5. [Velodyne website](https://velodynelidar.com/products/ultra-puck/)
+6. [ROS webpage](http://wiki.ros.org/velodyne)
+7. [ROS tutorial](http://wiki.ros.org/velodyne/Tutorials/Getting%20Started%20with%20the%20Velodyne%20VLP16)
diff --git a/docs/robots/accessories/sensors/sensors.mdx b/docs/robots/accessories/sensors/sensors.mdx
new file mode 100644
index 000000000..ec123e019
--- /dev/null
+++ b/docs/robots/accessories/sensors/sensors.mdx
@@ -0,0 +1,32 @@
+---
+title: Sensors Overview
+sidebar_label: Sensors
+sidebar_position: 1
+---
+
+
+
+
+
+This documentation should be considered a quick reference, rather than a complete technical data package from the sensor's Original Equipment Manufacturer.
+Every sensor page in our documentation has a _Further Reading_ section at the bottom, listing hyperlinks to the related ROS drivers, and OEM documentation.
+
+Also note that we have only listed the documentation of our most commonly used sensors.
+
+We suggest you:
+
+1. Review our documentation of the sensors related to your robot integration.
+2. Review the related _Further Reading_ section.
+3. If you are planning to purchase a sensor for standalone use, or for integration with a non-Clearpath system, consider visiting our Component Store, [store.clearpathrobotics.com](https://store.clearpathrobotics.com/).
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs/robots/common/_category_.json b/docs/robots/common/_category_.json
new file mode 100644
index 000000000..44fea45e2
--- /dev/null
+++ b/docs/robots/common/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Common",
+ "position": 7
+}
diff --git a/docs/robots/common/colours.mdx b/docs/robots/common/colours.mdx
new file mode 100644
index 000000000..5cd241377
--- /dev/null
+++ b/docs/robots/common/colours.mdx
@@ -0,0 +1,36 @@
+---
+title: Colours
+sidebar_position: 3
+---
+
+
+
+
+
+
+
+These are the materials and colours visible on the outside of our robots:
+
+| Material | Colour | Material Note |
+| :------------------------- | :----- | :-------------------------------------------------------------------------- |
+| Electroless Nickel Plating | Silver | |
+| Stainless Steel | Silver | |
+| Anodized Aluminum | Black | Anodic Coating, Type II Class 2 in Accordance With MIL-A-8625, Colour Black |
+| Powder Coating | Yellow | Tiger Drylac 49/22550 or 38/20006, Gloss, Smooth, Colour RAL 1006 |
+| Powder Coating | Black | Tiger Drylac 39/80200, Matte, Fine Texture, Colour "Black" |
+| Lettering | White | Polyurethane, RAL 7074 "Telegrey 4" |
+| Lettering | Black | Polyurethane, RAL 9005 "Jet Black" |
+| Rubber | Black | |
+| Plastic | Black | |
+
+
+
+:::info Customization
+
+Let our Sales team know if you need custom colours or graphics on your robot.
+We can work with our paint, silkscreen, and vinyl suppliers to make the customizations that you require.
+
+:::
diff --git a/docs/robots/common/components/_category_.json b/docs/robots/common/components/_category_.json
new file mode 100644
index 000000000..32d855aed
--- /dev/null
+++ b/docs/robots/common/components/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Components",
+ "position": 1
+}
diff --git a/docs/robots/common/components/components.mdx b/docs/robots/common/components/components.mdx
new file mode 100644
index 000000000..a5eade6d7
--- /dev/null
+++ b/docs/robots/common/components/components.mdx
@@ -0,0 +1,157 @@
+---
+title: Components Overview
+sidebar_label: Components
+sidebar_position: 1
+---
+
+
+
+
+
+The items listed on this page are common connectors, fasteners, and jellybeans that we frequently use in our robots.
+Refer to our [Sensors](../../accessories/sensors/sensors.mdx) and [Add-ons](../../accessories/add-ons/add-ons.mdx) sections for larger subassemblies.
+
+---
+
+## Connectors
+
+
+
+
+
+| Description | CPR item | Manufacturer item |
+| :----------------------------- | :------: | :---------------- |
+| M4 stud, 76 A maximum current | 023570 | 3049107 |
+| M5 stud, 125 A maximum current | 023068 | 3049204 |
diff --git a/docs/robots/common/physical_tools.mdx b/docs/robots/common/physical_tools.mdx
new file mode 100644
index 000000000..84f14e462
--- /dev/null
+++ b/docs/robots/common/physical_tools.mdx
@@ -0,0 +1,69 @@
+---
+title: Physical Tools
+sidebar_position: 2
+---
+
+These are the most common tools we use at Clearpath Robotics to build and maintain robots.
+There is a much longer list of tools we use to design, test, and build more complicated aspects of our robots—such as Printed Circuit Board Assemblies.
+The intention of this page is to show you what tools we use for maintenance, and for adding sensors to our robots.
+
+:::info Contact Us
+
+Contact our Sales team at \ if you want us to add sensors or custom attachments to your robot.
+We can suggest hardware and software that will meet your application goals.
+
+You can see some of our past Integration Services projects [here](https://clearpathrobotics.com/integration-services/).
+
+:::
+
+:::note
+
+Some tools are specific to the electrical connectors we use at Clearpath Robotics.
+For example, we show a Panduit crimper for ring terminals.
+This suggestion is because use Panduits ring terminals in our cable assemblies.
+There are other manufacturers that make comparable products, such as Molex, Phoenix Contact, and Tyco Electronics.
+
+:::
+
+| Category | Description | Preferred Manufacturer | Manufacturer Item Number |
+| :------------------------------- | :-------------------------------------------------------- | :---------------------- | :------------------------------------------------------------------------------------------------------------------------------- |
+| **Consumables** | Lint Free Cloth | Kimtech | |
+| | Isopropyl Alcohol | | |
+| | Thread Locker, Light | Loctite | [222](https://www.mcmaster.com/1810A27/) |
+| | Thread Locker, Medium | Loctite | [243](https://www.mcmaster.com/91458A115/) |
+| | Thread, Anti-Seize | Loctite | [8065](https://www.mcmaster.com/1019A11/) |
+| | Silicone Sealant | Dow Corning | [3138356](https://www.mcmaster.com/7587A2/) |
+| | Electrical Compound | | |
+| | Cable Ties | | |
+| **Mechanical Fabrication** | Rivet Installation Tool | Milwaukee | [2550-20](https://www.milwaukeetool.com/Products/Power-Tools/Specialty-Tools/Rivet-Tools/2550-20) |
+| | Drill | Milwaukee | [2606-20](https://www.milwaukeetool.com/Products/Power-Tools/Drilling/Drill-Drivers/2606-20) |
+| | Rotary Tool | Dremel | |
+| | Hole Deburring Tool | | |
+| **Mechanical Assembly** | Hex Keys, Metric | Wiha | [66980](https://www.digikey.ca/en/products/detail/wiha/66980/11658234) |
+| | Hex Keys, Imperial | Wiha | [66981](https://www.digikey.ca/en/products/detail/wiha/66981/11658233?s=N4IgTCBcDaICwGYCMBaAbGgnADlQOQBEQBdAXyA) |
+| | Crescent Wrenches, Metric (5 mm - 13 mm) | | |
+| | Crescent Wrenches, Imperial | | |
+| | Adjustable Wrench, Small | | |
+| | Adjustable Wrench, Large | | |
+| | Sockets and Socket Wrenches, Metric (5 mm - 13 mm) | | |
+| | Sockets and Socket Wrenches, Imperial | | |
+| | Sidecutters | Knipex | [78 03 125](https://www.digikey.ca/en/products/detail/knipex-tools-lp/78-03-125/10451639) |
+| **Electrical Cable Fabrication** | Soldering Iron | Pace | [MBT360](https://paceworldwide.com/mbt360-multi-channel-soldering-and-rework-station-w-td-200-and-sx-100) |
+| | Multimeter | Fluke | [115](https://www.digikey.ca/en/products/detail/fluke-electronics/FLUKE-115/1506332) |
+| | Soldering Helping Hands | | |
+| | Wire Strippers | Greenlee Communications | [PA1123](https://www.digikey.ca/en/products/detail/tempo-communications/PA1123/1990599) |
+| | Utility Knife | Olfa | [L-2](https://olfa.com/collections/professional/products/18mm-l-2-rubber-inset-utility-knife#shop) |
+| | Heat Gun | Milwaukee | [2688-20](https://www.milwaukeetool.com/Products/Power-Tools/Specialty-Tools/Heating-Tools/2688-20) |
+| | Crimper, Anderson Powerpole PP15 | Anderson Power Products | [1309G8](https://www.digikey.ca/en/products/detail/anderson-power-products-inc/1309G8/10647425?s=N4IgTCBcDaIIwGYAMBOA4gDhAXQL5A) |
+| | Crimper, Anderson SB50 and PP75 | Anderson Power Products | [1309G4](https://www.digikey.ca/en/products/detail/anderson-power-products-inc/1309G4/10650073) |
+| | Crimper, Molex Mini-Fit-Jr | Molex | [0638190901](https://www.digikey.ca/en/products/detail/molex/0638190901/9655931?s=N4IgTCBcDaIAwDYDMAOAjATjltIC6AvkA) |
+| | Extractor, Molex Mini-Fit-Jr | Molex | [11030044](https://www.digikey.ca/en/products/detail/molex/0011030044/210947?s=N4IgTCBcDaIIxwAwGZGICzpAXQL5A) |
+| | Crimper, Molex Mega-Fit | Molex | [2002187200](https://www.digikey.ca/en/products/detail/molex/2002187200/14311428?s=N4IgTCBcDa4AxzARgBwHYwJAXQL5A) |
+| | Extractor, Molex Mega-Fit | Molex | [0638240810](https://www.digikey.ca/en/products/detail/molex/0638240810/11657656?s=N4IgTCBcDaIGwGYAcYAsAGJBGdIC6AvkA) |
+| | Crimper, Ferrule (Phoenix Contact) | Phoenit Contact | [1213144](https://www.digikey.ca/en/products/detail/phoenix-contact/1213144/5875365) |
+| | Crimper, Ring Terminal (Panduit) | Panduit | [0638190901](https://www.digikey.ca/en/products/detail/panduit-corp/CT-1550/447992) |
+| | Crimper, Quick Disconnect (Panduit) | Panduit | [CT-1525](https://www.digikey.ca/en/products/detail/panduit-corp/CT-1525/447991?s=N4IgTCBcDaIMIBUC0BGArGNIC6BfIA) |
+| | Crimper, Ring Lug Terminals (Panduit) | Panduit | [CT-1700](https://www.digikey.ca/en/products/detail/panduit-corp/CT-1700/447996?s=N4IgTCBcDaIMYBcC0BGA7ABgyAugXyA) |
+| | Sidecutters | Knipex | [78 03 125](https://www.digikey.ca/en/products/detail/knipex-tools-lp/78-03-125/10451639) |
+| **Electrical Assembly** | Scouring Pads (ScotchBrite) | 3M | [61500290558](https://www.digikey.ca/en/products/detail/3m/61500290558/3589749) |
+| | Multimeter | Fluke | [115](https://www.digikey.ca/en/products/detail/fluke-electronics/FLUKE-115/1506332) |
diff --git a/docs/robots/indoor_robots/_category_.json b/docs/robots/indoor_robots/_category_.json
new file mode 100644
index 000000000..3f1c6ad02
--- /dev/null
+++ b/docs/robots/indoor_robots/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Indoor",
+ "position": 3
+}
diff --git a/docs/robots/indoor_robots/boxer/_category_.json b/docs/robots/indoor_robots/boxer/_category_.json
new file mode 100644
index 000000000..f542b3edf
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Boxer",
+ "position": 2
+}
diff --git a/docs/robots/indoor_robots/boxer/integration_boxer.mdx b/docs/robots/indoor_robots/boxer/integration_boxer.mdx
new file mode 100644
index 000000000..f6630ea59
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/integration_boxer.mdx
@@ -0,0 +1,80 @@
+---
+title: Boxer Integration
+sidebar_label: Integration
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionBoxer from "/components/introduction_boxer.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import Support from "/components/support.mdx";
+
+
+
+To attach custom hardware to Boxer, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+---
+
+### Mechanical Mounting
+
+When determining mechanical mounting, you can use the Standard mounting pattern on the top plate of the Boxer.
+At this time, the "PACS™" mounting system is not available for Boxer.
+
+#### Mechanical, Standard
+
+External payloads can be attached to the mounting plate of the Boxer by using the Ø8 mm countersunk through holes on the underside, or adding new holes.
+Whichever method you choose, the method for removing the top plate is the same and outlined below.
+
+1. Ensure the robot is shut off, and the circuit breaker is turned to the _off_ position.
+2. Disconnect and remove all existing payloads on the top plate.
+3. Using a 2 mm hex key, remove the twelve M3 round head screws holding the connection covers in place.
+ Remove the panels.
+ Take care to disconnect the network cable and attachment cable from the robot when removing the connection covers.
+4. Using a 4 mm hex key, remove the eleven M5 socket head screws holding the plate down.
+5. Remove the plate from the Boxer.
+
+The Boxer plate is made from 8 mm aluminum and can be easily machined according to your customization needs.
+
+The plate also has eight Ø8 mm holes in the corners which are countersunk from the underside of the plate, making them ideal for flathead screws installed to protrude from the plate.
+
+
+
+
+
+### Electrical Integration
+
+For connecting with any external payloads, such as a backpack computer, refer to the product's datasheet or manual.
+If your robot was equipped with these payloads by Clearpath Robotics this documentation is provided along with your Boxer.
+Contact [Support](#support) if you need more information.
+
+Ensure that the Boxer is shut off and the circuit breaker is turned to the _off_ position before performing any electrical work on the Boxer.
+
+The Boxer is equipped with an attachment interface that consists of a Power-over-Ethernet (PoE) RJ45 bulkhead connector, a USB Type-A bulkhead connector, and a 37-position panel receptacle and mated plug.
+To connect with the Boxer attachment interface see Section 10 of the [OTTO 100 V2.5 Operation and Maintenance Manual](https://docs.ottomotors.com/PDFs/100-v2.5-OMM.pdf).
+
+To add wires to the 37-position connector for you application, follow the TE Connectivity documentation for [connector 206305-1](https://www.te.com/usa-en/product-206305-1.html) to use appropriate crimp pins.
+Note that the 37-position connector will come pre-populated from Clearpath Robotics with 2 wires.
+These 2 wires complete the base Boxer's Motion Stop loop, allowing the robot to move.
+Other positions of the connector may be pre-populated, well as the PoE and USB, if your robot was equipped with payloads according to your Clearpath Robotics customizations.
+
+### Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../accessories/computers/computers.mdx)
+- [Sensors](../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support
+
+
diff --git a/docs/robots/indoor_robots/boxer/maintenance_boxer.mdx b/docs/robots/indoor_robots/boxer/maintenance_boxer.mdx
new file mode 100644
index 000000000..89350362c
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/maintenance_boxer.mdx
@@ -0,0 +1,62 @@
+---
+title: Boxer Maintenance
+sidebar_label: Maintenance
+sidebar_position: 4
+---
+
+import ComponentIntroductionBoxer from "/components/introduction_boxer.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Battery care
+
+To help extend the life of the batteries, follow the steps below.
+
+- Do not discharge the batteries lower than 10%.
+ Batteries lower than 5% are permanently damaged and cannot be recharged.
+- Recharge batteries to 100% after every use.
+- Recharge batteries and turn the circuit breaker to ”OFF” before putting the system into long-term storage.
+- Batteries that are in long-term storage will need to be recharged every 6 months.
+- Charge batteries when the ambient temperature is between 20 °C to 30 °C.
+ Consult Clearpath Robotics if you need to charge batteries outside these conditions.
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+Boxer is always being improved, both its own software and the many community ROS packages upon which it
+depends! You can use the apt package management system to receive new versions all software running on the
+platform.
+
+### Updating the Base Unit
+
+OTTO Motors periodically releases updates for the OTTO 100, which can be applied to Boxer's Base Unit.
+
+Please refer to [OTTO Motors' documentation](https://docs.ottomotors.com/en/30495-30532-installing-robot-software.html)
+for details on applying software updates.
+
+At the time of writing, the latest version of the OTTO 100 software supported by the Boxer's Noetic backpack is 2.22.3.
+
+### Updating the Backpack Computer
+
+The Backpack Computer can be updated by connecting it to the internet, either using a wired or wireless connection, and
+running the following commands:
+
+```
+sudo apt-get update
+sudo apt-get upgrade
+```
+
+If you see any errors, contact [Support](#support).
+
+### Starting From Scratch
+
+If Boxer's computer has become inoperable, or for any reason you want to restore it to the factory state,
+contact [Support](#support).
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/boxer/troubleshooting_boxer.mdx b/docs/robots/indoor_robots/boxer/troubleshooting_boxer.mdx
new file mode 100644
index 000000000..2a399ef7f
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/troubleshooting_boxer.mdx
@@ -0,0 +1,54 @@
+---
+title: Boxer Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 5
+---
+
+import ComponentIntroductionBoxer from "/components/introduction_boxer.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../accessories/sensors/sensors.mdx).
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/indoor_robots/boxer/tutorials_boxer.mdx b/docs/robots/indoor_robots/boxer/tutorials_boxer.mdx
new file mode 100644
index 000000000..8f5c1b2b5
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/tutorials_boxer.mdx
@@ -0,0 +1,288 @@
+---
+title: Boxer Tutorials
+sidebar_label: Tutorials
+sidebar_position: 3
+---
+
+import ComponentIntroductionBoxer from "/components/introduction_boxer.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Boxer Overview
+
+:::caution
+
+This guide is for the Boxer V2.4 (released in November 2021) and V2.5 (released in May 2023). Boxer V2.4 and V2.5 are not compatible with the older Boxer (V2.2).
+Owners of previous-generation (V2.2) Boxers should refer to the documentation [here](http://www.clearpathrobotics.com/assets/guides/kinetic/boxer/).
+
+:::
+
+:::note
+
+OTTO Motors and Clearpath Robotics operate under the same parent company.
+Boxer V2.4 and V2.5 are a collaboration between the teams at OTTO Motors and Clearpath Robotics.
+
+:::
+
+### Introduction
+
+Boxer is a large indoor mobile robot for prototyping and development of industrial applications.
+It is a lightly modified [OTTO 100](https://ottomotors.com/amrs) robot, equipped with a Backpack Computer mounted
+to the top of the Base Unit. This Backpack Computer communicates with the OTTO 100 via its attachment port, located
+on the top of the Base Unit.
+
+The Boxer is currently only supported in [ROS 1](/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/boxer/tutorials_boxer.mdx).
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/boxer).
+
+
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/boxer/user_manual_boxer.mdx b/docs/robots/indoor_robots/boxer/user_manual_boxer.mdx
new file mode 100644
index 000000000..79f30387b
--- /dev/null
+++ b/docs/robots/indoor_robots/boxer/user_manual_boxer.mdx
@@ -0,0 +1,596 @@
+---
+title: Boxer User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionBoxer from "/components/introduction_boxer.mdx";
+import Support from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+
+
+## Introduction
+
+Boxer is a large indoor mobile robot for prototyping and development of industrial applications.
+Adapted from the OTTO Motors _OTTO 100 autonomous mobile robot (AMR)_, Boxer is programmable
+and easily extensible with additional hardware.
+
+:::note
+
+Current Boxer shipments are based on OTTO 100 V2.5. Some shipments from 2021-2023 are based on
+OTTO 100 V2.4. All information in this manual applies equally to both versions except where
+otherwise noted.
+
+:::
+
+
+
+### Shipment Contents
+
+Your Boxer shipment contains the following:
+
+- Clearpath Robotics Boxer
+- OTTO 100 Manual Charger
+- Handheld Joystick Controller
+- Optional: OTTO 100 Fast Charger
+
+If you elected to purchase standard payload modules or custom integration services with Boxer, then additional equipment will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Boxer is built on the OTTO 100 AMR, which provides the core locomotion, safety, and sensing capabilities, along with a ROS 2 API
+for control of the system. Boxer is typically augmented with a Backpack Computer, which allows for user software to be installed
+and executed on the system, controlling the Base Unit through the ROS 2 API over a local Ethernet connection. The backpack
+computer also allows for control and monitoring of any additional payloads added to Boxer.
+
+#### Exterior Features
+
+Below is an overview of the Boxer robot hardware that outlines the key components that you should be aware of in order to get started
+with using your robot. Note that the front emergency stop button is only present on Boxer V2.5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+#### Human-Machine Interface (HMI) Panel
+
+The back of Boxer has the Human-Machine-Interface panel _(HMI)_.
+The HMI has 5 elements:
+
+1. Ethernet port
+2. Power button
+3. Emergency stop reset button
+4. Chargeport
+5. Rear emergency stop button
+
+
+
+
+
+#### Front Emergency Stop Button
+
+In addition to the rear emergency stop button described in the HMI Panel above, Boxer 2.5 (but not Boxer 2.4)
+has a front emergency stop button, which is mounted to the right of the front safety LiDAR. Refer to
+[Emergency Stop Buttons](#boxer-stop-buttons) for additional details.
+
+
+
+
+
+
+
+#### Body Lights
+
+Boxer includes RGB LED strips around its body. These lights express system status according to the table below.
+
+| LED Pattern | System State |
+| :------------ | :-------------------------------------------------------------------------- |
+| Solid Red | Robot is starting up |
+| Flashing Red | Robot is emergency stopped or safety stopped |
+| Circling Blue | Base Unit is in Manual mode, allowing it to be controlled via the ROS 2 API |
+
+At present these lights are not controllable through any ROS topics.
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+
+ Boxer Coordinate System
+
+
+
+### System Specifications
+
+| Specification | Measurement |
+| :--------------------------------- | :---------- |
+| Dimensions, Length | 740 mm |
+| Dimensions, Width | 550 mm |
+| Dimensions, Height | 320 mm |
+| Mass | 114 kg |
+| Velocity, Max | 2.0 m/s |
+| Obstacle, Max Step Height | 6 mm |
+| Obstacle, Floor Gap | 13 mm |
+| Operating Relative Humidity, Min | 0 % |
+| Operating Relative Humidity, Max | 85 % |
+| Operating Temperature, Min | 20 °C |
+| Operating Temperature, Max | 30 °C |
+| Storage Temperature, Min | -20 °C |
+| Storage Temperature, Max | 35 °C |
+| Operating Time, Standby | 8 hours |
+| Operating Time, Continuous Driving | 3 hours |
+
+---
+
+## Getting Started
+
+### Unboxing
+
+Boxer ships fully assembled and no assembly is required.
+To unbox, remove the screws holding the top wood panel and the front wood panel.
+Remove the screws holding the cross bracing.
+An electric driver should be used to aid in the removal of the screws.
+Lay the top wood panel down with one end on the edge of the crate and the other end on the ground to create a ramp as shown below.
+Pull the robot out of the crate by hand, and then roll the robot down the wood ramp.
+
+
+
+
+
+### Powering Up
+
+1. Turn the 2 circuit breakers to the on position.
+ You will need to lift the metal bar to do this.
+
+
+
+2. Press the Power Button.
+
+
+
+3. Wait for the system to boot.
+ The Boxer's lights will go through a sequence of colors during this process:
+
+ - All white for approximately 30 seconds
+ - All red for approximately 30 seconds
+ - Flashing white for less than 5 seconds
+ - Then flashing red
+
+ Note that the Boxer will be sounding an alarm which will be adjusted during the base unit configuration below.
+
+### Base Unit Configuration
+
+Connect the Boxer to the Wi-Fi network using the steps below.
+Refer to [Connecting to a robot using an Ethernet cable](https://docs.ottomotors.com/en/30495-30527-connecting-to-a-robot-using-ethernet.html) and
+[Connecting a robot to a network](https://docs.ottomotors.com/en/30495-30526-connecting-a-robot-to-a-network.html) for more details.
+
+1. Configure a network port on your laptop with the IP address \<10.255.255.200\>.
+2. Connect a network cable from the port on your laptop to the network port on the rear of the Base Unit.
+
+
+
+3. On your laptop, open a web-browser like Google Chrome, and go to the address http://10.255.255.1:8090
+4. Enter the required information to connect to your network.
+ See your IT administrator for proper settings for your network.
+
+
+
+
+
+
+5. Take note of the hostname.
+ It will be used in future steps for accessing the robot.
+ You can also find this hostname engraved on the HMI panel, at the rear of the Boxer.
+6. Click _Save and Restart Network_.
+7. Power cycle the Boxer.
+8. Using the hostname or static IP set in the Wi-Fi setup above, load the _OTTO App_ user interface by opening a web-browser, and going to the address _http://hostname:5000_.
+ (e.g. [http://A31-002124076:5000](http://A31-002124076:5000) )
+ The _OTTO App_ should load, and look similar to the image below.
+
+
+
+9. Adjust the volume to an appropriate level for your facility by selecting the _Vehicle_ option from the top-left menu and adjusting the volume as appropriate.
+
+
+
+10. You have finished onfiguring the Boxer Base Unit, and it's ready for use.
+
+### Backpack Computer Configuration
+
+This section outlines how to configure the Backpack Computer attached to the Base Unit.
+You can omit this section if your Boxer is not equipped with a Backpack Computer.
+
+The Backpack Computer is an add-on computer that is networked with the Base Unit's computer, located inside then Boxer.
+This Backpack Computer can be used to integrate peripherals, like sensors and manipulators.
+A ROS bridge automatically runs upon booting the Backpack Computer, and transmits the Base Unit computer's ROS data to the Backpack Computer.
+This ROS bridge allows you to leverage the Base Unit for your own application.
+The Backpack Computer uses Netplan as its network configuration tool, and has a static IP address of \<192.168.131.1\>.
+
+#### Connecting to the Backpack Computer
+
+You can connect to the Backpack Computer on Boxer over a wired or Wi-Fi connection.
+
+To connect to the Backpack Computer over a wired connection:
+
+1. Configure a network port on your laptop with the IP address \<192.168.131.100\>.
+2. Connect a network cable from your laptop to an open network port on the Backpack Computer.
+3. Test the connection between the user computer and Backpack Computer by opening a terminal and entering: `ping 192.168.131.1 `
+4. From your laptop's terminal, you can access the Backpack Computer by entering: `ssh administrator@192.168.131.1`
+
+To connect to the Backpack Computer over a Wi-Fi connection:
+
+1. Connect your laptop to the same Wi-Fi network as the Backpack Computer.
+2. Note the IP address of the Backpack Computer's wireless interface by running this command the Backpack Computer's terminal: `ip a`
+3. To test the connection between your laptop and Backpack Computer, enter this command in a terminal from your laptop: `ping ` (eg. `ping 192.168.0.11`)
+4. From your laptop's terminal, you can access the Backpack Computer by entering: `ssh administrator@` (eg. `ssh administrator@192.168.0.11`)
+
+#### Connecting the Backpack Computer to a Wi-Fi Network
+
+To connect the Backpack Computer to a wireless network follow these steps:
+
+1. Access the Backpack Computer over an SSH connection.
+ Since the Backpack Computer is presumably not connected to a Wi-Fi network yet, you will need to access the Backpack Computer over a wired connection.
+ The previous section details how to connect to the Backpack Computer over a wired connection.
+2. Once you have accessed the Backpack Computer, create a netplan configuration by running the following command.
+
+ sudo touch /etc/netplan/60-wifi.yaml
+
+ This will create a file called _60-wifi.yaml_ inside of the _/etc/netplan/_ directory.
+
+3. Open _/etc/netplan/60-wifi.yaml_ with your favourite text editor and populate it.
+ Use this example configuration file as reference:
+
+ ```
+ network:
+ wifis:
+ # change wlp2s0 to exactly match your wireless interface
+ # common values are wlp2s0, wlp3s0, wlan0, etc...
+ # if you aren't sure, use the `iwconfig` or `ip a` command
+ wlp2s0:
+ optional: true
+ access-points:
+ # replace "my-ssid" with the SSID of your wireless network
+ my-ssid:
+ # put your wireless password here
+ password: wifi_password_goes_here
+ # DHCP4 should be enabled for most wireless routers
+ # alternatively you can use a static IP address.
+ # e.g, uncomment the following
+ #addresses: [192.168.1.100/24]
+ #gateway: 192.168.1.1
+ #dhcp4: false
+ dhcp4: true
+ dhcp4-overrides:
+ send-hostname: true
+ ```
+
+4. Connect the Backpack Computer to the wireless network by running the command below.
+ Note that this may take a moment to complete:
+
+ ```
+ sudo netplan apply
+ ```
+
+5. To verify that the Backpack Computer is connected to the wireless network, check that the Backpack Computer has an IP address assigned to its wireless interface by running:
+
+ ```
+ ip a
+ ```
+
+### Battery Charging
+
+The system can be charged using an [OTTO 100 Manual Charger](https://ebikes.ca/product-info/grin-products/cycle-satiator.html) or an [OTTO 100 Fast Charger](https://docs.ottomotors.com/en/84902-86097-100-fast-charger.html).
+Details for use and installation are provided in the linked User Manuals.
+
+Only use the OTTO 100 Manual Charger or OTTO 100 Fast Charger provided with your Boxer.
+Use of other chargers may cause damage or injury.
+
+---
+
+## Operation
+
+This section outlines how to use the basic functions of the Boxer platform in order to get started quickly.
+There are several methods of operating the robot.
+
+### Getting Started with the OTTO User Interface
+
+This section details how to get the Robot driving around using the OTTO user interface.
+
+1. Power on the system.
+2. Ensure that all emergency stop buttons are released by pulling out the red buttons at the front (V2.5 only) and rear of the unit, and then pressing the blue emergency stop Reset button.
+
+
+
+
+
+
+3. Using the base Boxer's hostname or static IP, open the OTTO App by entering the following in your laptop's web-browser:
+
+ http://\:5000
+
+4. You are now ready to start driving your system.
+
+### Driving Manually
+
+To drive the robot manually, follow the steps below.
+
+1. Power up the robot and connect to the OTTO App at `http://:5000`
+2. The first time after power-up, it is necessary to take the system out of neutral by clicking on the joystick icon at the bottom right of the interface.
+
+
+
+3. Ensure that the system is in manual mode and use the _thumbstick_ at the bottom right of the interface to drive the robot in the desired direction.
+ Note that the maximum speed can be adjusted using the slider _Tortoise-Hare_ at the bottom of the interface.
+ We recommended you begin at slow speeds until you become comfortable with how to control the robot.
+
+
+
+
+### Mapping
+
+Prior to navigating autonomously, a map of the facility must be created.
+The details of creating a map are beyond the scope of this document.
+Detailed instructions for mapping can be found here:
+
+- [OTTO App training](https://otto.talentlms.com/)
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Boxer and powered on.
+If your purchased the Backpack Computer from Clearpath Robotics, your controller is already paired with your Boxer.
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the
+[Boxer Tutorials](tutorials_boxer.mdx).
+
+To use the controller:
+
+1. Power up the robot and connect to the OTTO App at `http://:5000`
+2. The system will boot up into a neutral state.
+ Take the robot out of _Neutral_ by clicking the _Joystick_ icon at the bottom right of the interface.
+3. Release all emergency stop buttons and press the emergency stop reset button.
+4. Press the PS button on the controller to sync with the robot.
+ Once the blue LED on the top of the controller is solid, the Robot is paired and ready to move.
+ Hold the L1 trigger button to engage the enable switch.
+ Push the left thumbstick in the direction you wish to move the Boxer.
+5. For full speed mode, hold the R1 trigger.
+ Note that it is recommended that you use full speed mode only when comfortable with the operation of the Boxer.
+
+
+
+
+### Using ROS
+
+
+
+
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+The Boxer robot contains several features to protect the safety of users and the integrity of the vehicle.
+
+### General Warnings
+
+Use of an autonomous robot is inherently dangerous.
+
+For the safety of yourself and others, always conduct initial experiments and software development with
+the robot raised off the ground. Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any
+other solid flat structure under Boxer to keep the wheels clear of the
+ground ("up on blocks").
+
+When starting out, favour slower wheel speeds.
+Operating at such speeds will allow for more reaction time in the case of unexpected behaviour.
+
+When the robot is operating, keep clear of the wheels.
+
+Refer to the [OTTO 100 V2.5 Operation and Maintenance Manual](https://docs.ottomotors.com/PDFs/100-v2.5-OMM.pdf) for further safety precautions when using self-driving vehicles.
+
+### Emergency Stop Buttons {#boxer-stop-buttons}
+
+:::warning
+
+Ensure the emergency stop buttons are accessible at all times.
+Avoid mounting payloads that extend over the front or rear of Boxer and would occlude the emergency stop buttons.
+
+:::
+
+Please take time to locate the red emergency stop buttons on the front (V2.5 only) and rear and of the system.
+The emergency stop function allows a person in the physical vicinity of the robot to halt its motion and prevent re-initiation of motion.
+This emergency stop system is intended for use in emergency situations.
+The emergency stop system should not be used as the means of controlling robot motion during regular operation.
+
+When any emergency stop button is pressed, it provides a secure way to stop the robot movement, but does not control power attached by the attachment panel.
+The emergency stop function can be reset by pulling out all the red emergency stop buttons until they return to an extended position and then pressing the emergency stop reset button.
+The robot may begin moving again immediately after the emergency stop reset button has been pressed.
+
+When in emergency stop mode, the light strip will be flashing red and Boxer will not drive.
+The commands received during emergency stop mode are not buffered; Boxer will always act on the latest commands received.
+This means that if the commands are stopped before the stop is released, the Boxer will not move.
+If the commands are continued, Boxer will move at the speed commanded once the stop is released.
+
+### Safety Lidars
+
+Boxer is also equipped with safety lidars in the front and back that will cause the robot to lose power if a collision is predicted,
+or if the robot is operating too fast in an enclosed environment. The safety stop is automatic, and is not controlled through any ROS
+topics. Once the danger has passed the safety stop will automatically disengage.
+
+If Boxer seems to be stuck in a safety stop, check that there is no dirt or debris on either the front or rear lidars. Wipe the
+lidars down using an appropriate lidar wipe or soft cloth to remove any dirt.
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## Support
+
+
diff --git a/docs/robots/indoor_robots/dingo/_category_.json b/docs/robots/indoor_robots/dingo/_category_.json
new file mode 100644
index 000000000..7af794442
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Dingo",
+ "position": 1
+}
diff --git a/docs/robots/indoor_robots/dingo/integration_dingo/_category_.json b/docs/robots/indoor_robots/dingo/integration_dingo/_category_.json
new file mode 100644
index 000000000..e5f1838f9
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/integration_dingo/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Integration",
+ "position": 3
+}
diff --git a/docs/robots/indoor_robots/dingo/integration_dingo/integration_dingo.mdx b/docs/robots/indoor_robots/dingo/integration_dingo/integration_dingo.mdx
new file mode 100644
index 000000000..eb52834ee
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/integration_dingo/integration_dingo.mdx
@@ -0,0 +1,258 @@
+---
+title: Dingo Integration
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionDingo from "/components/introduction_dingo.mdx";
+import ComponentPacsMechanical from "/components/pacs_mechanical.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import Support from "/components/support.mdx";
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+
+
+To attach custom hardware to Dingo, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+---
+
+### Mechanical Mounting
+
+When determining mechanical mounting, you have two options, both of which are described below.
+
+- the "Standard" mounting pattern on Dingo's trough cover
+- the "PACS™" mounting system and associated kits
+
+#### Mechanical, Standard
+
+A standard Dingo is delivered with an 80 mm square mounting pattern of M5 threaded holes on Dingo's trough cover as shown
+in [Exterior Features](../user_manual_dingo.mdx#dingo-exterior-features), which can be used for attaching external payloads.
+The mounting holes come with M5 screws pre-installed.
+You may mount your hardware directly onto the trough cover or you may design and mount a new plate to the trough cover and secure it to the trough cover using M5 screws.
+
+#### Mechanical, PACS™
+
+
+
+Refer to the following pages for Dingo brackets that can simplify your integration.
+
+- [Top Plate](kits/top_plate_dingo.mdx)
+- [Riser Full](kits/riser_full_dingo.mdx)
+
+### Electrical Integration {#dingo-payload-electrical-integration}
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+
+#### Data Connections
+
+Data connections may be brought through the openings in the trough cover and connected directly to the internal computer.
+
+Dingo's internal computer options support USB3 and Ethernet connectivity.
+In addition, the PCIe Gen3 x16 slot may be used to supply a GPU or other attachements, as necessary.
+Additionally, the internal mounting area may be used for an Ethernet switch, when attaching multiple Ethernet payloads, or for a PoE power injector as required.
+
+#### Connector Summary
+
+The Dingo MCU board provides a number of connections for power, relays, auxiliary inputs and auxiliary outputs.
+These are summarized in the following table and described in more detail in the following sections.
+
+| MCU board label | MCU board connector | Mating connector | Crimp terminals | Crimping tool |
+| :--------------- | :---------------------------------------------------------- | :---------------------------------------------------------- | :----------------------------------------------------------- | :--------------- |
+| PWR1, PWR2 | Dingo 1.0: Molex 0039301040 Dingo 1.5: Molex 0039302040 | Dingo 1.0: Molex 0039012040 Dingo 1.5: Molex 0039014041 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+| VBAT | Molex 768250002 | Molex 1700010102 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+| INPUTS | TE 3-794682-8 | TE 794617-8 | TE 1-794610-1 (AWG 20-24) or TE 1-794611-1 (AWG 26-30) | TE 91391-1 |
+| SW_IN | TE 2-1445094-2 | TE 1445022-2 | TE 1-794610-1 (AWG 20-24) or TE 1-794611-1 (AWG 26-30) | TE 91391-1 |
+| AUX1, AUX2, AUX3 | TE 3-794682-4 | TE 794617-4 | TE 1-794610-1 (AWG 20-24) or TE 1-794611-1 (AWG 26-30) | TE 91391-1 |
+| RELAY | TE 4-794682-0 | TE 1-794616-0 | TE 1-794610-1 (AWG 20-24) or TE 1-794611-1 (AWG 26-30) | TE 91391-1 |
+| FAN | Molex 0533750210 | Molex 0511630200 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+| ESTOP | Molex 053370610 | Molex 0511630600 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+
+#### User Power Connections
+
+The following are available as user power: unregulated battery power (see VBAT), regulated 12 V power (see PWR1 and PWR2), and regulated 5 V power (see PWR1 and PWR2).
+
+Similar to the data connections, the power leads may be brought through the trough cover and connected to the user power.
+Remove the front trough cover by removing four flathead screws and locate the appropriate power connector on the MCU board.
+Refer to the figure below for the location of the user power connectors.
+Route the power from the MCU board to the appropriate location, either to the internal payload modules or through the openings in the trough cover to the topside payload.
+
+
+
+
+
+
+ Dingo 1.0 MCU and User Power
+
+
+
+
+
+
+
+ Dingo 1.5 MCU and User Power
+
+
+
+
+
+#### AUX Inputs {#dingo-aux-inputs}
+
+The Dingo MCU includes an 8-pin `INPUTS` connector and a 2-pin `SW_IN` connector that allow the user to provide inputs to the system.
+The user can then subscribe to these inputs on the `/mcu/aux_inputs` ROS topic.
+The AUX inputs are mapped to the ROS message bits as follows:
+
+- IN1: bit 0
+- IN2: bit 1
+- IN3: bit 2
+
+Electrically, the `INPUTS` connector is used for IN1 and IN2, with pin mapping as outlined below.
+Note that each of the two inputs can be 12 V or 24 V inputs, with a shared return path.
+The inputs have opto-electrical isolation.
+
+- 1: 12 V power (for external input circuit, if needed)
+- 2: IN1 return
+- 3: GND (for external input circuit, if needed)
+- 4: IN2 return
+- 5: IN1 12 V input
+- 6: IN1 24 V input
+- 7: IN2 12 V input
+- 8: IN2 24 V input
+
+Electrically, the `SW_IN` connector is used for IN3, with pin mapping as outlined below.
+This is intended to be a 'switch' input and it generates a 100 ms pulse to the microcontroller when asserted.
+
+- 1: 3.3 V input (IN3)
+- 2: GND
+
+#### AUX Outputs and Relay {#dingo-aux-outputs}
+
+The Dingo MCU includes three user-controlled outputs (AUX1, AUX2, AUX3), that can be controlled by publishing to the `/mcu/aux_outputs` ROS topic.
+To enable the AUX outputs, simply publish a single message with the appropriate bits set to 1 to turn the output on and 0 to turn it off.
+The state does not persist meaning new commands will need to keep the bit enabled as well.
+The AUX outputs are mapped to the ROS message bits as follows:
+
+- AUX1: bit 0
+- AUX2: bit 1
+- AUX3: bit 2
+
+For example, to disable all AUX outputs:
+
+```
+rostopic pub /mcu/aux_output std_msgs/UInt8 "data: 0"
+```
+
+For example, to enable all AUX outputs:
+
+```
+rostopic pub /mcu/aux_output std_msgs/UInt8 "data: 7"
+```
+
+For example, to enable just the AUX3 output:
+
+```
+rostopic pub /mcu/aux_output std_msgs/UInt8 "data: 4"
+```
+
+Each of the AUX outputs is a 4-pin connector with pin mapping as outlined below.
+
+**AUX1 Pin Mapping**
+
+- 1: VSYS (shore power or battery power) with 5 A fuse
+- 2: VSYS (shore power or battery power) with 5 A fuse
+- 3: GND
+- 4: GND
+
+**AUX2 Pin Mapping**
+
+- 1: 12 V with 5 A fuse
+- 2: 12 V with 5 A fuse
+- 3: GND
+- 4: GND
+
+**AUX3 Pin Mapping**
+
+- 1: 5 V with 5 A fuse
+- 2: 5 V with 5 A fuse
+- 3: GND
+- 4: GND
+
+**Relays**
+
+In addition to the AUX output connectors, publishing to `/mcu/aux_outputs` also
+controls the AUX relays. These relays are available through the 10-pin
+connector on the MCU labelled `RELAY` with pin mapping:
+
+- 1 and 6: 12 V with 2 A fuse
+- 5 and 10: GND
+- 2 and 7: AUX1 relay closed with aux_outputs bit 0 is '1'
+- 3 and 8: AUX2 relay closed with aux_outputs bit 1 is '1'
+- 4 and 9: AUX3 relay closed with aux_outputs bit 2 is '1'
+
+#### Optional Fan {#dingo-fan}
+
+While a fan is not included by default with Dingo, a fan may be integrated into the system.
+Electrically, connect a 12 V 2-pin fan to the MCU connector labelled `FAN` using a mating connector.
+The pins should be connected as follows:
+
+- 1: 12 V @ 500mA max
+- 2: GND
+
+Then, the use can publish a ROS message to the `/mcu/fans` topic to control the fan.
+
+#### Optional External Motion Stop {#dingo-external-motion-stop}
+
+In addition to the built-in Motion Stop button, an external motion-stop button can be added that has similar functionality.
+Electrically, the external motion-stop button can be connected to the 6-pin MCU connector labelled `ESTOP` using a mating connector.
+
+The six pins should be connected as follows:
+
+- 1-2: to an external "normally closed" motion-stop breakout button:
+ - press to engage the motion stop
+ - twist and release the external motion stop button to clear the motion-stop
+ - to re-enable the motors, the Motion Stop Button on the HMI panel must be pressed
+- 3-4: short these pins to indicate that external motion-stop is selected
+- 5-6: short these pins to indicate that external motion-stop is present
+
+#### MCU Debug LEDs
+
+The Dingo MCU PCBA comes equipped with four LEDs controlled by Dingo firmware for debugging.
+If the system is working properly, these LEDs functions as follows:
+
+- **DBG1**: toggles every 500 ms when main loop on MCU is running
+- **DBG2**: on if MCU connected to ROS on computer; else false (same as COMMS LED on HMI)
+- **DBG3**: toggles when MCU is relaying messages from CAN bus to computer
+- **DBG4**: toggles when MCU is relaying messages from computer to CAN bus
+
+### Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../../accessories/computers/computers.mdx)
+- [Sensors](../../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/dingo/integration_dingo/kits/_category_.json b/docs/robots/indoor_robots/dingo/integration_dingo/kits/_category_.json
new file mode 100644
index 000000000..29029fd60
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/integration_dingo/kits/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Kits",
+ "position": 2
+}
diff --git a/docs/robots/indoor_robots/dingo/integration_dingo/kits/riser_full_dingo.mdx b/docs/robots/indoor_robots/dingo/integration_dingo/kits/riser_full_dingo.mdx
new file mode 100644
index 000000000..43bf58d45
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/integration_dingo/kits/riser_full_dingo.mdx
@@ -0,0 +1,101 @@
+---
+title: Full Riser
+sidebar_position: 3
+---
+
+
+
+:::note
+
+We suggest you to remove the 3rd and 5th rows of screws from the front of the Dingo-D or Dingo-O.
+You can choose different locations to suit your application, but this will require custom URDF software work.
+
+:::
+
+### Step 2
+
+Insert the male threaded side of the shafts _(ID2)_ into the holes where you removed the screws in _Step 1_.
+
+:::note
+
+Torque these shafts to 5 N·m if you are concerned about them loosening from high vibration applications.
+
+:::
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 3
+
+Repeat this for the 3 remaining shafts.
+
+### Step 4
+
+Place the riser's plate on top of the shafts.
+The plate is symmetrical, so there is not a front / back side.
+
+### Step 5
+
+Fasten the plate using 4 screws _(ID3)_
+
+:::note
+
+Torque these screws to 5 N·m if you are concerned about them loosening from high vibration applications.
+
+:::
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/indoor_robots/dingo/integration_dingo/kits/top_plate_dingo.mdx b/docs/robots/indoor_robots/dingo/integration_dingo/kits/top_plate_dingo.mdx
new file mode 100644
index 000000000..d4e6f8aff
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/integration_dingo/kits/top_plate_dingo.mdx
@@ -0,0 +1,14 @@
+---
+title: Top Plate
+sidebar_position: 2
+---
+
+
+
+
+
+The standard top plates for the Dingo include M5×0.8 threaded holes that match the Clearpath PACS™ standard.
+These top plates are included with all Dingo-D and Dingo-O robots.
diff --git a/docs/robots/indoor_robots/dingo/maintenance_dingo.mdx b/docs/robots/indoor_robots/dingo/maintenance_dingo.mdx
new file mode 100644
index 000000000..56c7d6919
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/maintenance_dingo.mdx
@@ -0,0 +1,92 @@
+---
+title: Dingo Maintenance
+sidebar_label: Maintenance
+sidebar_position: 5
+---
+import ClearpathFirmware from "../../../components/_clearpath_firmware.mdx";
+import ComponentIntroductionDingo from "/components/introduction_dingo.mdx";
+import ComponentLeadAcidBatteryCare from "/components/maintenance/lead_acid_battery_care.mdx";
+import ComponentLeadAcidBatteryCareTips from "/components/maintenance/lead_acid_battery_care_tips.mdx";
+import ComponentLifepo4BatteryCareTips from "/components/maintenance/lifepo4_battery_care_tips.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Battery Care
+
+### Lead-Acid Battery Care
+
+Dingo's default power supply is a sealed 12 V lead-acid battery pack (VRLA), providing 20 Ah of charge.
+These tips are intended to help keep your Dingo Lead-Acid Battery in tip-top shape.
+With proper maintenance, the battery should maintain the majority of its capacity for hundreds of cycles.
+
+
+
+Your robot's battery charger works in 3 stages:
+
+1. Constant current charging or bulk charge (9 to 14.6 V @ 6 A): indicator LED is red
+2. Constant voltage charging or topping charge (14.6 V @ 6 A down to 2 A): indicator LED is red
+3. Trickle or Float charge (14.6 V @ 2 A down to 0 A): indicator LED is green
+
+The bulk of the capacity (70%) is regained during the first stage.
+
+It is important to let the charger complete all 3 stages whenever possible, to help maintain the life of the battery.
+The initial stage will take 3 - 5 hours, and a complete charge may take up to 10 hours, depending on the
+depth of discharge.
+
+
+
+Your robot's battery charger works in 3 stages:
+
+1. Constant current charging or bulk charge (9 to 14.6 V @ 6 A): indicator LED is red
+2. Constant voltage charging or topping charge (14.6 V @ 6 A down to 2 A): indicator LED is red
+3. Trickle or Float charge (14.6 V @ 2 A down to 0 A): indicator LED is green
+
+The initial stage will take 5 - 7 hours, and a complete charge may take up to 14 hours.
+
+### LiFEPO4 Battery Care
+
+:::note
+
+LiFEPO4 are not available for Dingo 1.0. They are only available for Dingo 1.5 and newer.
+
+:::
+
+Dingo's optional power supply is a Lithium Iron Phosphate battery pack (LiFEPO4),
+providing minimum 20 Ah of charge. These tips are intended to help keep your Dingo LiFEPO4 Battery
+in tip-top shape. With proper maintenance, the battery should maintain the majority of its capacity for
+thousands of cycles, typically a 10x increase over SLA batteries.
+
+The LiFEPO4 battery charger works in 3 stages:
+
+1. Constant current charging or bulk charge (9 to 14.6 V @ 7 A): indicator LED is red
+2. Constant voltage charging or topping charge (14.6 V @ 7 A down to 0.7 A): indicator LED is red
+3. Balancing or Float charge (14.6 V @ 0.7 A down to 0 A): indicator LED is green
+
+The bulk of the capacity (70%) is regained during the first stage.
+
+It is important to let the charger complete all 3 stages whenever possible, to help maintain the life of the battery.
+The initial stage will take 2 - 4 hours, and a complete charge may take up to 8 hours, depending on the depth of discharge.
+
+
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+
+
+---
+
+## Support {#support}
+
+
+
+---
diff --git a/docs/robots/indoor_robots/dingo/troubleshooting_dingo.mdx b/docs/robots/indoor_robots/dingo/troubleshooting_dingo.mdx
new file mode 100644
index 000000000..9df6913c5
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/troubleshooting_dingo.mdx
@@ -0,0 +1,54 @@
+---
+title: Dingo Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 6
+---
+
+import ComponentIntroductionDingo from "/components/introduction_dingo.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../accessories/sensors/sensors.mdx).
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/indoor_robots/dingo/tutorials_dingo.mdx b/docs/robots/indoor_robots/dingo/tutorials_dingo.mdx
new file mode 100644
index 000000000..918532a67
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/tutorials_dingo.mdx
@@ -0,0 +1,32 @@
+---
+title: Dingo Tutorials
+sidebar_label: Tutorials
+sidebar_position: 4
+---
+
+import ComponentIntroductionDingo from "/components/introduction_dingo.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Dingo Overview
+
+### Introduction
+
+Dingo a lightweight and easy-to-use unmanned indoor ground vehicle for ROS, suitable for research and rapid prototyping applications.
+
+
+
+The Dingo is currently only supported in [ROS 1](/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/dingo/tutorials_dingo.mdx).
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/dingo).
+
+### Jetson Installation
+
+Refer to the [Jetson](../../accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx) page for details on installing a Jetson in Dingo.
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/dingo/user_manual_dingo.mdx b/docs/robots/indoor_robots/dingo/user_manual_dingo.mdx
new file mode 100644
index 000000000..518384a33
--- /dev/null
+++ b/docs/robots/indoor_robots/dingo/user_manual_dingo.mdx
@@ -0,0 +1,635 @@
+---
+title: Dingo User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionDingo from "/components/introduction_dingo.mdx";
+import ComponentSupport from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+
+
+## Introduction
+
+Dingo is a lightweight and easy-to-use unmanned indoor ground vehicle for ROS.
+
+There are two Dingo variants:
+
+- **Dingo-D** uses differential drive and has two module bays, one of which must be a battery module; the second module is typically a computer module.
+- **Dingo-O** uses omnidirectional drive and has four module bays, at least two of which are typically battery modules; the other modules may be computer modules or networking equipment.
+
+
USB cable (x1): USB Cable, Type A to Micro B (0.3 m)
+
Molex connectors (x2): Molex P/N - 0039012040
+
Molex crimp pins (x8): Molex P/N - 0039000073
+
Fuse 5A (x1): Littelfuse Inc. P/N - 0891005.NXS
+
Fuse 10A (x1): Littelfuse Inc. P/N - 0891010.NXS
+
Fuse 20A (x1): Littelfuse Inc. P/N - 0891020.NXS
+
Fuse 30A (x1): Littelfuse Inc. P/N - 0891030.NXS
+
+
+
+
+
+
Dingo UGV (Dingo-D or Dingo-O variant)
+
One or more batteries of the following type:
+
+
12 V sealed lead-acid (SLA) batteries
+
+ 12.8 V LiFEPO4 batteries
+
+
+
One universal charger for your batteries
+
One Sony PS4 Bluetooth controller
+
One Dingo quick start guide
+
Accessories:
+
+
USB cable (x1): USB Cable, Type A to Micro B (0.3 m)
+
Molex connectors (x2): Molex P/N - 0039014041
+
Molex crimp pins (x8): Molex P/N - 0039000073
+
Fuse 5A (x1): Littelfuse Inc. P/N - 0891005.NXS
+
Fuse 10A (x1): Littelfuse Inc. P/N - 0891010.NXS
+
Fuse 20A (x1): Littelfuse Inc. P/N - 0891020.NXS
+
+
+
+
+
+If you elected to purchase standard payload modules or custom integration services with Dingo, then additional equipment will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Dingo is built around a computer running Ubuntu (Intel-based computer or Jetson developer kit), paired with a 32-bit microcontroller MCU.
+The MCU handles I/O, power supply monitoring, and motor control, as well as supplying data from the integrated IMU.
+The communication channel between the MCU and computer is a 100 Mbps Ethernet connection.
+
+#### Exterior Features {#dingo-exterior-features}
+
+The exteriors of Dingo-D and Dingo-O are shown below and include:
+
+- External payload mounts on the top trough cover;
+- 98.4 mm diameter wheels (Dingo-D) or 101.6 mm diameter mechanum wheels (Dingo-O);
+- Human machine interface panel (HMI);
+- Top (yellow) fairings;
+- Side access panels;
+- Front panel connectors (Dingo 1.5 only):
+ - Wired battery charger port
+ - DC shore power port
+ - WiBotic wireless battery charge port (optional, not shown)
+
+
+
+
+
+
+
+#### Human-Machine Interface (HMI) Details
+
+The human-machine-interface (HMI) panel is shown below and includes from left:
+
+| Icon | Description |
+| :---------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| | **Motion Stop button**: LED is solid green when Dingo is able to drive and is flashing green when the Dingo's motors are disengaged; pressing button toggles the motors between engaged and disengaged mode (further details in [Motion Stop Buttons](#dingo-stop-buttons)); LED is not illuminated when connected to DC shore power or to the wired charger (as the robot is prevented from moving in this state) |
+| | **Comms indictor**: LED is solid green when communication between the MCU and computer has been established and LED is off otherwise |
+| | **Wi-Fi indicator**: LED is solid green when Wi-Fi is connected and LED is off otherwise |
+| | **Battery indicator**: LED is solid green when the battery level is ok, flashing green when connected to DC shore power, solid yellow when the battery level is getting low (should be charged soon), and solid red when the battery level is critical (should be charged immediately) |
+| | **System Power button**: LED is solid blue when the system is powered on and running and the LED is flashing blue during the shutdown process; when the system is powered off, pressing the power button begins the power on process; when the system is powered on, a quick press of the power button begins a graceful shutdown and a prolonged press of the power button triggers and immediate power off of the system |
+
+
+
+
+ HMI Panel
+
+
+
+#### Payload Details
+
+The interiors of Dingo-D and Dingo-O are shown below along with example payload modules.
+
+To access Dingo's payload modules (computers or batteries), simply slide and remove the top (yellow) fairings.
+To access Dingo's MCU PCBA (for user power), remove the four M5 flathead screws from the top trough cover, and then remove the trough cover.
+
+
+
+
+
+
+ Area inside Dingo-D 1.0, with example modules
+
+
+
+
+
+ Area inside Dingo-O 1.0, with example modules
+
+
+
+
+
+
+
+ Area inside Dingo-D 1.5, with example modules
+
+
+
+
+
+ Area inside Dingo-O 1.5, with example modules
+
+
+
+
+
+#### Corner LEDs and System State
+
+Dingo is equipped with LEDs at the four corners of the robot, which indicate the state of the system:
+
+
+
+
+
+
+
System State (lowest to highest priority)
+
Corner LED Output
+
+
+
+
+
Idle
+
Front LEDs solid white (low intensity), rear LEDs solid red (low intensity)
+
+
+
Driving
+
Front LEDs solid white (medium intensity), rear LEDs solid red (medium intensity)
+
+
+
Low Battery
+
Pulsing orange LEDs
+
+
+
Reset Required
+
Adjacent corners alternating between red and off
+
+
+
Motion Stop Engaged
+
Flashing red LEDs
+
+
+
System Fault
+
Flashing orange LEDs
+
+
+
+
+
+
+
+
+
System State (lowest to highest priority)
+
Corner LED Output
+
+
+
+
+
Idle
+
Front LEDs solid white (low intensity), rear LEDs solid red (low intensity)
+
+
+
Driving
+
Front LEDs solid white (medium intensity), rear LEDs solid red (medium intensity)
+
+
+
Low Battery
+
Pulsing orange LEDs
+
+
+
Reset Required
+
Adjacent corners alternating between red and off
+
+
+
Motion Stop Engaged
+
Flashing red LEDs
+
+
+
+ Charging: wired or wireless (Dingo 1.5 only)
+
+
Pulsing green LEDs
+
+
+
Shore Power Connected
+
Pulsing blue LEDs
+
+
+
+ Shore Power Connected and Charging (Dingo 1.5 only)
+
+
Pulsing green to blue LEDs
+
+
+
Puma Fault
+
Flashing red LED on Puma at fault, solid red for other corners
+
+
+
+ Shore Power Fault (Dingo 1.5 only)
+
+
Flashing blue and red LEDs
+
+
+
Battery Fault
+
Flashing yellow and red LEDs
+
+
+
LED Command Timeout
+
Solid red
+
+
+
+
+
+
+While in "Idle" and "Driving" states, the user can override the LEDs by publishing to the `/mcu/lights` topic.
+
+#### DC Shore Power
+
+Dingo provides a DC Shore Power connection ([internal connector for Dingo 1.0](integration_dingo/integration_dingo.mdx#dingo-payload-electrical-integration); [external connector for Dingo 1.5](#dingo-exterior-features))
+to allow the system to be powered without requiring batteries to be present. Note that when DC Shore Power is connected, the motors are disabled and it is not possible to drive the
+Dingo; however, all other electronics (computers, sensors, etc) will remain enabled.
+
+
+
+ For Dingo 1.0, to connect the shore power, remove the top trough cover (to access the MCU) and then attach the shore power cable to the 2-port connector labelled "SHORE" on the MCU.
+
+
+ For Dingo 1.5, users can also connect the manual charger while using DC Shore Power to allow the batteries to charge fully with no load present on them. The DC Shore Power supply is an off the shelf Mean Well power supply, part number GST280A15-C6P. This power supply is a 15V, 225W AC/DC converter with a 6 position
+ Molex connector that plugs into the mating port on the front of the Dingo.
+
+
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855.
+
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+### System Specifications
+
+| Specification | Dingo-D (Differential Drive) | Dingo-O (Omnidirectional Drive) |
+| :------------------------- | :----------------------------------------------------------------------- | :----------------------------------------------------------------------- |
+| Dimension, Length | 551 mm | 686 mm |
+| Dimension, Width | 517 mm | 517 mm |
+| Dimension, Height | 110 mm | 114 mm |
+| Ground Clearance | 14 mm | 16 mm |
+| Mass | 12 kg | 17.5 kg |
+| Maximum Modules | 2 | 4 |
+| Maximum Payload | 20 kg | 25 kg |
+| Speed, Maximum | 1.3 m/s | 1.3 m/s |
+| Operating Environment | Indoor | Same as Dingo-D |
+| Operating Time (Dingo 1.0) | 2 hours (1X SLA), 4 hours (1X Lithium) | 2 hours (2X SLA), 4 hours (2X Lithium) |
+| Operating Time (Dingo 1.5) | 2 hours (1X SLA), 4 hours (1X LiFEPO4) | 2 - 6 hours (1X - 3X SLA), 3.5 - 11 hours (1X - 3X LiFEPO4) |
+| Battery Chemistry | Sealed Lead-Acid or Lithium (Dingo 1.0) / LiFEPO4 (Dingo 1.5) | Same as Dingo-D |
+| Charge Time | 3.3 hours (1X SLA) or 3.0 hours (1X LiFEPO4) | 3.3 - 10 hours (1X - 3X SLA) or 3 - 9 hours (1X - 3X LiFEPO4) |
+| User Power (Dingo 1.0) | 20 A @ VBAT (11 - 16.8 V), 7A @ 12 V, 5 A @ 5 V | Same as Dingo-D |
+| User Power (Dingo 1.5) | 20 A @ VBAT (11 - 15 V), 10A @ 12 V, 5 A @ 5 V | Same as Dingo-D |
+| Communication | Ethernet, USB 3.0 | Same as Dingo-D |
+| Internal Sensing | Battery Status, Wheel Odometry, Motor Currents, Onboard IMU | Same as Dingo-D |
+
+
+
+
+
+---
+
+## Getting Started
+
+You are ready to go! This section details how to get Dingo into action.
+To begin, place Dingo "up on blocks" as described in the [Safety](#safety) section, making sure that the wheels are clear of the ground.
+
+For most Dingo setups, there will be an Onboard Computer which is directly connected to the Dingo and an Offboard Computer which is used to control Dingo and gather data.
+These two computers must be set up to communicate with each other.
+
+### Onboard Computer Setup
+
+If you purchased an Onboard Computer from Clearpath Robotics with Dingo, it is already installed, connected, and powered.
+If not, or to set up your own Onboard Computer, see the [Dingo Tutorials](tutorials_dingo.mdx).
+
+Note that the Onboard Computer must be connected to Dingo's Ethernet port, which is accessible in the center channel.
+
+### Powering Up
+
+If you've just unpacked Dingo from its packaging, you may need to open it up and connect the battery.
+
+Press the power button on Dingo's HMI panel.
+The LEDs should show a test pattern, after which you will wait about 30 seconds for the internal computer to finish booting up.
+Once it has finished booting, the Comms indicator should turn green.
+This indicates that ROS is up on the computer and has established communications with the Dingo base.
+
+### Network Configuration
+
+To get Dingo connected to your local Wi-Fi network, you must first access the Onboard Computer using a wired connection to the robot.
+Remove the top trough cover and the appropriate yellow fairing to access the computer module, then connect to one of the network ports with a standard Ethernet cable.
+See the [Dingo Tutorials](tutorials_dingo.mdx) for details.
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Dingo and powered on.
+If your purchased the Onboard Computer from Clearpath Robotics, your controller is already paired with your Dingo.
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the [Dingo Tutorials](tutorials_dingo.mdx).
+
+To teleoperate Dingo, first clear the motion-stop.
+Then, power on the controller by pressing the `PS` button on the controller.
+Once the blue LED on the top of the controller goes solid, you are paired and ready to drive.
+
+Hold the L1 trigger button (deadman switch) and push the left thumbstick forward to drive the Dingo.
+For full speed mode, hold the R1 trigger.
+See the figure below for the Sony PS4 controls layout.
+If you are not seeing any action, refer to [Support](#dingo-support) to get in touch with support.
+
+
+
+
+ PS4 Controls Layout
+
+
+
+### Using ROS
+
+
+
+### Battery Charging
+
+
+
+ For Dingo 1.0, when finished with the Dingo, press and release the power button to power it off.
+ Then remove the batteries for charging.
+
+ Dingo's batteries are charged outside the Dingo using the charger(s) provided.
+
+ Alternatively, if you have multiple batteries, you can hot-swap them one at a time.
+ The system will remain operational while hot-swapping as long as there is at least one battery in the system or the system is connected to shore power prior to removing the batteries.
+ Note that plugging in shore power will engage a motion-stop and it is not possible to drive Dingo while connected to shore power.
+
+ The Sealed Lead-Acid batteries have overcurrent protection in the form of an ATO fuse.
+ The lithium batteries include integrated protections against fault due to overcurrent, overdischarge, and short circuit.
+ The batteries are rugged and designed for the demanding environments into which Dingo may be deployed.
+
+
+ For Dingo 1.5, to charge the batteries, simply connect the manual charger to the charge port on the front of the Dingo. Charging can take place while the unit is powered,
+ or unpowered, or while the unit is connected to DC Shore Power. The charging current for the SLA system is 6A, and 7A for the LiFEPO4 system. Care must be
+ taken when charging while the system is powered, as if the load/total current is higher than the supplied charge current the batteries will continue to drain.
+ If the total system current is less than the charge current the batteries will charge, but at a reduced rate as the system will be using a portion of the
+ charger current to maintain operation.
+
+
+
+For multi-battery systems the charge current is distributed across the number of batteries present in the system, so charging time will increase appropriately.
+Care should be taken when removing or installing batteries. The batteries must be at the same charge level or voltage before connecting them together in the system.
+The easiest way to ensure this is to have an external charger, and by charging each battery individually with that charger to a full charge so all batteries are at
+the same charge level (or voltage). Once at the same level it is ok to connect them together in the unit. Failure to follow this procedure can result in
+battery/system damage and/or personal injury.
+
+However, please take note of the following:
+
+- SLA batteries must be charged while in a 0 to +45 ◦C range and discharged while in a -30 to +60 ◦C range.
+- Lithium batteries must be charged while in a 0 to +50 ◦C range and discharged while in a -20 to +60 ◦C range.
+- LiFEPO4 batteries must be charged within a 0 to +45 ⁰C range and discharged while in a -20 to +60 ⁰C range.
+- Chargers must be placed on a hard surface, not on a carpet or other insulating device, as they can get hot during the bulk charging phase.
+
+Please contact Clearpath Robotics for additional information about Dingo's batteries or for information about purchasing additional batteries.
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+Dingo contains several features to protect the safety of users and the integrity of the robot.
+
+:::caution
+
+Dingo is a fast moving robotic platform. Please read the following notices carefully.
+
+:::
+
+### General Warnings
+
+Dingo is a rugged and high-performance vehicle.
+For the safety of yourself and others, always conduct initial experiments and software development with the vehicle raised off the ground.
+Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any other solid flat structure having a height greater than 150 mm (6 inches) under Dingo to keep the wheels clear of the ground ("up on blocks").
+
+When starting out, favour slower wheel speeds.
+Dingo's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+### Motion Stop Buttons {#dingo-stop-buttons}
+
+The Motion Stop button is located on the HMI Panel at the back of Dingo.
+To engage Stop Mode, press the Motion Stop button once; you should see that the green LED by the Motion Stop button is flashing and that all four corner LEDs are flashing red.
+To disengage Stop Mode, press the Motion Stop button again; all LEDs should return to their original values.
+
+When in Stop Mode, the Dingo will not drive.
+The commands received while in Stop Mode are not buffered; Dingo will always act on the latest commands received.
+This means that if the commands are stopped before the Motion Stop button is pressed to disengage Stop Mode, the Dingo will not move.
+If the commands are continued, Dingo will move at the speed commanded once the Motion Stop button is pressed to disengage Stop Mode.
+
+Ensure that the Motion Stop button is accessible at all times.
+Avoid mounting payloads that extend over the rear of Dingo and would block access to the Motion Stop button.
+
+Note that the Dingo MCU board does provide a breakout to allow an external motion-stop button/switch to be integrated by the end user, which could be used to engage/disengage Stop Mode.
+See [Optional External Motion Stop](integration_dingo/integration_dingo.mdx#dingo-external-motion-stop) for details on adding an external motion-stop button/switch.
+
+### Electrical System
+
+Dingo is powered by batteries capable of delivering over 2000W for short durations.
+This gives Dingo's motors their great performance; however, it is also enough power to cause severe bodily harm.
+Always use caution when operating Dingo to avoid personal injury or property damage.
+To ensure safety, please observe the following precautions:
+
+- Do not tamper with the battery terminals or wiring.
+- Do not tamper with the fuses, except to check and change the fuses.
+- Always replace fuses with the same type and rating to ensure continued protection against risk of fires.
+- Consult Clearpath Robotics support if you need to service the batteries.
+- Do not lay tools or other objects on top of the batteries.
+- Charge the battery only with the charger provided by Clearpath Robotics.
+- Please dispose of the batteries properly or return them to Clearpath Robotics to do so.
+
+### Lifting and Transport
+
+- Ensure that Dingo's Stop Mode is engaged when transporting short distances and powered off when transporting longer distances.
+- Do not push the robot at more than 0.5 m/s (1.6 ft/s) or damage to the motor controls may occur.
+
+### Performance Considerations
+
+Included in Dingo are native software checks and limits to protect the robot.
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## Support {#dingo-support}
+
+
diff --git a/docs/robots/indoor_robots/ridgeback/_category_.json b/docs/robots/indoor_robots/ridgeback/_category_.json
new file mode 100644
index 000000000..8288a653f
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Ridgeback",
+ "position": 3
+}
diff --git a/docs/robots/indoor_robots/ridgeback/integration_ridgeback.mdx b/docs/robots/indoor_robots/ridgeback/integration_ridgeback.mdx
new file mode 100644
index 000000000..45e4c9ef8
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/integration_ridgeback.mdx
@@ -0,0 +1,168 @@
+---
+title: Ridgeback Integration
+sidebar_label: Integration
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionRidgeback from "/components/introduction_ridgeback.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import Support from "/components/support.mdx";
+
+
+
+To attach custom hardware to Ridgeback, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+---
+
+### Mechanical Mounting
+
+When determining mechanical mounting, you can use the Standard mounting pattern on the Ridgeback.
+At this time, the "PACS™" mounting system is not available for Ridgeback.
+
+#### Mechanical, Standard {#ridgeback-payload-mechanical-integration}
+
+The payload integration plate can be used to mount external payloads on top of the Ridgeback. The plate
+is made of aluminum, which allows Ridgeback to support payloads up to 100 kg (220 lbs). Ridgeback's
+batteries are positioned low in the chassis and slightly rearward of center of the robot to balance the
+weight distribution when mounting front-facing manipulator payloads. To minimize the possibility of tipping
+over, payload structures should always be mounted as close to center as possible.
+
+##### Payload Mounting Holes
+
+Located at the front-end of the mounting plate are two 5/8"-11 screw holes for mounting Baxter, UR5/UR510 manipulator
+arms, or any other payload structure. These holes are indicated in the figure below. If you purchased the Baxter
+or UR5/UR10 package from Clearpath Robotics, Ridgeback will come with the required hardware adapters to securely mount
+the payload structures to the plate.
+
+If your payload structure requires additional mounting holes or a different hole configuration, the plate can be removed
+and additional holes can be drilled. To remove the mounting plate, simply remove the screws that form the diamond pattern
+on top of the plate.
+
+
+
+
+ Payload integration plate
+
+
+
+:::warning
+
+Permanent damage resulting from custom modifications to the mounting plate is not covered under warranty and may not be
+supported by Clearpath Support. Please contact our support team if you require assistance or have any questions relating
+to custom modifications.
+
+:::
+
+### Electrical Integration {#ridgeback-payload-electrical-integration}
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+
+#### Data Connections
+
+The two larger holes on the left and right side of the payload integration plate allow you to pass
+electrical wires and cables from the mounted payloads into the User Bay. Electrical wires should always
+pass through the provided plastic grommets to protect against cutting and abrasion.
+
+Ridgeback's internal computer options support USB3 and Ethernet connectivity.
+
+An Ethernet switch or PoE power injector can be added to the User Bay as required.
+
+#### Connector Summary {#ridgeback-connector-summary}
+
+Several user power connectors are accessible in the User Bay for powering user payloads.
+These are summarized in the following table and described in more detail in the following sections.
+The power rails on the User Bay Power board are protected against short circuit by fuses. See the
+illustration for the connector and fuse locations.
+
+- For the High Current VBAT User Power (labelled as 24 VDC, 20 A MAX), terminate your payload's power lead with the appropriate Anderson connectors.
+- For the User Power Ports, terminate your payload's power lead with the appropriate crimps and pins.
+ for the four pin Molex connector. The maximum current draw permitted on each rail is 5A.
+- For the Inverter Power, terminate your payload's power lead with the appropriate Anderson connectors.
+
+| Port (see Figure) | MCU board connector | Mating connector | Crimp terminals | Crimping tool |
+| :--------------------------- | :----------------------------------------------------------------------- | :------------------------------------------------- | :----------------------------------------------------------- | :--------------- |
+| High Current VBAT User Power | Anderson PP15/45 1327-BK (red) + 1327G6-BK (black) + Anderson 261G2-LPBK | Anderson PP15/45 1327-BK (red) + 1327G6-BK (black) | Anderson 262G2-LPBK (AWG 16-20) or 261G3-LPBK (AWG 10-14) | Anderson 1309G8 |
+| User Power Ports | Molex 0039301040 | Molex 0039012040 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+| Inverter Power | Anderson 1327G8-BK (blue) + 1327G6-BK (black) | Anderson 1327G8-BK (blue) + 1327G6-BK (black) | Anderson 262G2-LPBK (AWG 16-20) or 261G3-LPBK (AWG 10-14) | Anderson 1309G8 |
+
+
+
+
+ User power board
+
+
+
+#### User Power Connections
+
+Similar to the data connections, power leads may be brought through the two larger holes on the left and
+right side of the payload integration plate, and connected to the power ports in the User Bay.
+The following are available as user power:
+
+- Unregulated VBAT power (25.6 V nominal) available in two ways:
+ - High Current VBAT User Power (20 A max)
+ - User Power ports: 5 A, shared across the User Power ports
+- Regulated 12 V power: 5 A, shared across the User Power ports
+- Regulated 5 V power: 5 A, shared across the User Power ports.
+
+:::caution
+
+Each User Power Port (Molex 0039301040) has a shared ground (GND) pin with a maximum current rating of 8 A. Ensure
+that the combined current draw for the VBAT, 12 V, and 5 V pins for the corresponding GND
+pin does not exceed 8 A.
+
+:::
+
+:::caution Unregulated Power Rail
+
+The unregulated battery output may range from as low as 20 VDC up to 30 VDC depending on the state of charge of
+the battery and the electrical loading on the system. Ensure any accessories connected to that rail are able to
+deal with unregulated battery voltages.
+
+:::
+
+:::warning Risk of Fire
+
+For continued protection against risk of fire, always replace fuses only with those of the same type and rating.
+
+:::
+
+#### Optional External Motion Stop {#ridgeback-external-motion-stop}
+
+In addition to the built-in Motion Stop button, an external motion-stop latching button/switch can be added that has similar functionality.
+Electrically, the external motion-stop latching button/switch can be connected to the 4-pin MCU connector labelled `E-STOP BREAKOUT` using
+a mating connector. This 4-pin connector is the same as the one used for the User Power Ports. Refer to
+[Connector Summary](#ridgeback-connector-summary) for details.
+
+The four pins should be connected as follows:
+
+- 1-2: to external motion-stop breakout
+ - To engage motion-stop: press and release the latching button/switch (3.3 V)
+ - To clear motion-stop: ensure the button is released on the external motion stop, then press and release the Motion Stop button on the
+ Ridgeback unit to clear the motion-stop
+- 3-4: short these pins to indicate that external motion-stop is present
+
+### Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../accessories/computers/computers.mdx)
+- [Sensors](../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/ridgeback/maintenance_ridgeback.mdx b/docs/robots/indoor_robots/ridgeback/maintenance_ridgeback.mdx
new file mode 100644
index 000000000..d7c2a8ebc
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/maintenance_ridgeback.mdx
@@ -0,0 +1,54 @@
+---
+title: Ridgeback Maintenance
+sidebar_label: Maintenance
+sidebar_position: 4
+---
+import ClearpathFirmware from "../../../components/_clearpath_firmware.mdx";
+import ComponentIntroductionRidgeback from "/components/introduction_ridgeback.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Battery Replacement
+
+If Ridgeback's batteries need replacement, they are accessible by removing the top-plate and the insulator
+cover. Before performing any service or maintenance to the robot, the battery pack must be fully disconnected.
+The batteries weigh approximately 33 kg (73 lbs) each, so use care and caution when lifting the
+batteries out of the chassis. Please contact Clearpath Robotics regarding replacement batteries.
+
+It may also be necessary to remove the antenna cables carefully prior to removing the batteries.
+
+## Long-term storage
+
+When storing Ridgeback for long periods of time, its important to properly maintain the batteries to fully
+maximize their life. Consider one of the following two procedures when placing Ridgeback in long-term storage:
+
+- Fully charge Ridgeback, turn it off and put it into storage. Once a week, connect power to the charger
+ and allow the charger to top up the battery for an hour or so.
+- Fully charge Ridgeback, turn it off and put it into storage, but leave the charger connected and powered
+ the entire time Ridgeback is in storage via a wall timer that turns off for one hour every 24-hour cycle.
+ The charger will monitor the battery and will automatically charge it up as needed. Note that the wall
+ timer is needed since the charger times out and turns off otherwise.
+
+Please contact Clearpath Robotics for additional information about Ridgeback's batteries.
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+
+
+---
+
+## Support {#support}
+
+
+
+---
diff --git a/docs/robots/indoor_robots/ridgeback/troubleshooting_ridgeback.mdx b/docs/robots/indoor_robots/ridgeback/troubleshooting_ridgeback.mdx
new file mode 100644
index 000000000..97de97591
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/troubleshooting_ridgeback.mdx
@@ -0,0 +1,54 @@
+---
+title: Ridgeback Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 5
+---
+
+import ComponentIntroductionRidgeback from "/components/introduction_ridgeback.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../accessories/sensors/sensors.mdx).
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/indoor_robots/ridgeback/tutorials_ridgeback.mdx b/docs/robots/indoor_robots/ridgeback/tutorials_ridgeback.mdx
new file mode 100644
index 000000000..2c689fd31
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/tutorials_ridgeback.mdx
@@ -0,0 +1,29 @@
+---
+title: Ridgeback Tutorials
+sidebar_label: Tutorials
+sidebar_position: 4
+---
+
+import ComponentIntroductionRidgeback from "/components/introduction_ridgeback.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Ridgeback Overview
+
+### Introduction
+
+Ridgeback is a rugged, indoor omnidirectional platform designed to move manipulators and other heavy
+payloads with ease and precision.
+
+
+
+The Ridgeback is currently only supported in [ROS 1](/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/ridgeback/tutorials_ridgeback.mdx).
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/ridgeback).
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx b/docs/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx
new file mode 100644
index 000000000..291cdfc80
--- /dev/null
+++ b/docs/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx
@@ -0,0 +1,328 @@
+---
+title: Ridgeback User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionRidgeback from "/components/introduction_ridgeback.mdx";
+import ComponentSupport from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+
+
+## Introduction
+
+Clearpath Robotics Ridgeback is a rugged, indoor omnidirectional platform designed to move manipulators and other heavy
+payloads with ease and precision. This manual contains information about the setup, safe operation, and maintenance of
+your Ridgeback unmanned omnidirectional platform.
+
+
+
+### Shipment Contents
+
+Your Ridgeback shipment contains the following:
+
+- Ridgeback Omnidirectional Robotic Platform, including computer, forward-facing LIDAR, batteries, and integrated
+ battery charger
+- One Sony PS4 Bluetooth controller
+- One Ridgeback quick start guide
+
+If you elected to purchase standard payload modules or custom integration services with Ridgeback, then additional
+equipment will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Ridgeback is built around a computer running Ubuntu (Intel-based computer or Jetson developer kit), paired with a 32-bit microcontroller MCU.
+The MCU handles I/O, power supply monitoring, and motor control, as well as supplying data from the integrated IMU.
+The communication channel between the MCU and computer is a Gigabit Ethernet connection.
+
+#### Exterior Features {#ridgeback-exterior-features}
+
+The exterior of Ridgeback is shown below and includes:
+
+- Stop, Reset, and Power buttons
+- Body Lights
+- User Bay
+- Payload Integration Plate
+
+
+
+
+ Ridgeback exterior
+
+
+
+#### Buttons
+
+There are four push buttons located on the back of the Ridgeback: the two red mushroom Stop buttons, the
+Stop Reset button below the left rear Stop button, and the Power ON/OFF button below the rear right
+Stop button. On the front of the robot, there are another two red mushroom Stop buttons. These buttons
+are described further in the table below.
+
+| Button | Description |
+| :----------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Power ON/OFF | Turns Ridgeback on or off. Note that the power button is a soft, momentary switch: to shut Ridgeback down, press and release it, and when the Onboard Computer has completed a safe power-down, the robot itself will also power-down. |
+| 4X Stop | Stops Ridgeback by placing the four integrated motor drivers into an electrical reset condition. This is intended as a backup option for immobilizing Ridgeback when autonomy software malfunctions or commands unintended motion. The Stop buttons have a mechanical latch, which can be released by twisting the latched button. If you have a wireless Stop pendant, or other stop-asserting hardware you would like to integrate with Ridgeback, a breakout header is supplied on the main microcontroller PCB. |
+| Stop Reset | Clears the electrically-enforced stop latch, allowing Ridgeback to run again after it has been stopped via one of the Stop buttons. Note that the mushroom button's mechanical latch must be cleared before the electrical reset can have any effect. |
+
+#### Body Lights
+
+Ridgeback includes eight RGB body lights, stacked in a pair on each corner of the chassis. These lights
+express system status according to the table below, but in the absence of one of the low-level conditions, they can
+be commanded from ROS to display indications from autonomy or other higher-level software.
+See http://wiki.ros.org/ridgeback_base for information on commanding the body lights.
+
+| Front Lights | Rear Lights | System State |
+| :------------------ | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Solid red | Solid red | The MCU is not in contact with the computer. That is, the `rosserial` connection is not active. This condition will be seen briefly on startup while Ridgeback's computer is booting up. If it persists, or is seen after initialization, either the base node on the computer has crashed, the network switch has failed, or a serious MCU error has occurred. If you suspect one of these conditions, please contact support. |
+| Flashing red | Flashing red | Stop mode is engaged. To disengage, twist the mushroom buttons to ensure that they are unlatched, and check any external stop hardware, if present. |
+| Flashing orange | Flashing orange | A system fault has been detected, typically the motor drivers. Refer to logs or diagnostics for details. |
+| Pulsing orange | Pulsing orange | Battery is low. Connect Ridgeback to the charger. |
+| Alternating red/off | Alternating red/orange | All stops are mechanically cleared but still electrically latched. Press the Stop Reset button to enable full operation. |
+| Pulsing green | Pulsing green | Charger is connected, Ridgeback's battery is charging. Note that the battery can also be charged with the platform off. This indication will only be seen if the charger is connected while Ridgeback is powered up. |
+| Solid green | Solid green | Charger is connected and Ridgeback is charged fully. |
+| Solid white | Solid red | Normal operation; ready to drive. The intensity of the lights will increase slightly when actually in motion. This is the status which may be overridden by publishing your own light patterns to the `/cmd_lights` ROS topic. |
+
+#### User Bay
+
+The User Bay provides access to the User Power Panel, as well as USB and Ethernet ports, and additional
+space for stowing user equipment. The electrical panel can be used to power your payloads, with further details available
+in [Electrical Integration](integration_ridgeback.mdx#ridgeback-payload-electrical-integration).
+The USB3 ports are connected directly to the Onboard Computer, and the Ethernet ports connect to the onboard network switch. To
+connect a device to the onboard network, it is suggested to give it a static IP in the 192.168.131.x/24 subnet and
+this cannot be changed since the MCU is statically set to 192.168.131.2 and expects the computer to be at
+192.168.131.1. Avoid IPs in use by the following pre-existing devices:
+
+| IP Address | Device Assignment |
+| :------------- | :--------------------------------------------------- |
+| 192.168.131.1 | Onboard Computer (both ports, br0 network interface) |
+| 192.168.131.2 | Ethernet-connected MCU |
+| 192.168.131.20 | Front-facing LIDAR |
+| 192.168.131.21 | Rear-facing LIDAR (if present) |
+
+See [Network IP Addresses](../../../ros/networking/network_ip_addresses.mdx) for a full list of common IP addresses.
+
+#### Payload Integration Plate
+
+The Payload Integration Plate provides a robust foundation for mounting payload structures such as
+UR5/UR10 manipulation arms or any other combination of sensors and manipulators. For more information
+and guidance on mounting payload structures on top of Ridgeback, please refer to
+[Mechanical Integration](integration_ridgeback.mdx#ridgeback-payload-mechanical-integration).
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855.
+
+When commanded with a positive translational velocity (forward), wheels travel in the positive x-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+### System Specifications
+
+| Specification | Measurement |
+| :-------------------- | :--------------------------------------------------------------------------- |
+| Dimension, Length | 960 mm |
+| Dimension, Width | 793 mm |
+| Dimension, Height | 311 mm † |
+| Ground Clearance | 18 mm |
+| Maximum Payload | 100 kg |
+| Speed, Maximum | 1.1 m/s |
+| Operating Environment | Indoor |
+| Operating Time | 15 hours with max payload (24 V 100 Ah) |
+| Battery Chemistry | Marine Grade AGM Sealed Lead Acid |
+| Charge Time | 8 hours |
+| User Power | 20 A @ VBAT (24 V), 5 A @ 12 V, 5 A @ 5 V |
+| Power | 800 W Typical Use, Shore Power Available |
+| Control Modes | Kinematic control (forward, sideways, rotation), individual wheel velocities |
+| Communication | Ethernet, USB 3.0, RS232 |
+| Internal Sensing | Battery Status, Wheel Odometry, Motor Currents, Onboard IMU |
+
+† The height of the Ridgeback was increased by 15 mm starting with the robot with serial number R100-0111. Older Ridgebacks measure 296 mm high.
+
+
+
+
+
+---
+
+## Getting Started
+
+You are ready to go! This section details how to get Ridgeback into action.
+If you are just opening up the shipping crate, you can unfold the ramp, and remove the ratchet straps which
+secure Ridgeback during shipping.
+
+To begin, place Ridgeback "up on blocks" as described in the [Safety](#safety) section, making sure that the wheels
+are clear of the ground.
+
+### Onboard Computer Setup
+
+A standard Ridgeback ships with an integrated Onboard Computer that is directly connected to the Ridgeback MCU. Most users
+will also make use of an Offboard Computer, which is used to control Ridgeback and gather data.
+These two computers must be set up to communicate with each other. Details on the Offboard Computer setup
+can be found in [Ridgeback Tutorials](tutorials_ridgeback.mdx).
+
+### Powering Up
+
+Press the power button on the back of Ridgeback. Once the body lights are flashing red, clear the all Stop
+buttons (if necessary), and press the blinking red Stop Reset button. In a moment, the platform should go to
+solid red lights in back, and solid white in front.
+
+### Network Configuration
+
+To get Ridgeback connected to your local Wi-Fi network, you must first access the Onboard Computer using a wired connection to the robot.
+Open the User Bay, then connect to one of the network ports with a standard Ethernet cable.
+Then, see [Ridgeback Tutorials](tutorials_ridgeback.mdx) for details
+on completing the networking setup.
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Ridgeback and powered on.
+For a standard Ridgeback with the Onboard Computer from Clearpath Robotics, the controller is already paired with your Ridgeback.
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the
+[Ridgeback Tutorials](tutorials_ridgeback.mdx).
+
+To teleoperate Ridgeback, first clear the motion-stop.
+Then, power on the controller by pressing the `PS` button on the controller.
+Once the blue LED on the top of the controller goes solid, you are paired and ready to drive.
+
+Hold the L1 trigger button (deadman switch) and push the left thumbstick forward to drive the Ridgeback.
+See the figure below for the Sony PS4 controls layout.
+If you are not seeing any action, refer to [Support](#ridgeback-support) to get in touch with support.
+
+
+
+
+ PS4 Controls Layout
+
+
+
+### Using ROS
+
+
+
+### Battery Charging
+
+Ridgeback uses two 8A31DTM Group-31 lead-acid (PbSO4) deep-cycle AGM batteries mounted low in the
+chassis. They provide an output of 24 VDC (nominal) and 100 Ah of capacity.
+
+When finished with the Ridgeback, press and release the power button to power it off.
+
+Ridgeback has an internal charger. All that is required to charge Ridgeback is to open the User Bay access
+panel, locate the charger power cord and plug it into any 85-270 VAC 50/60Hz mains outlet. The robot can be
+turned "on", though we recommend against driving the robot when the battery is charging.
+
+The battery pack is rugged and designed for the environments into which Ridgeback may be deployed.
+However, please take note of the following:
+
+- The batteries and robot must not be stored or operated above 50 ◦C or below -20 ◦C.
+- If the robot is to be stored for any length of time it should be in a cool, dry location. The batteries should
+ be fully charged and periodically maintained at full charge to ensure a long service life. Ridgeback
+ should not be stored with a low state of charge nor for extended periods of time without top-up charging.
+ The batteries may suffer from "sulfation" which reduces their capacity and lifetime.
+- Do not allow the batteries to reach a depth of discharge of 80%.
+- The batteries must not be punctured or disassembled.
+- The batteries should be disposed of pursuant to your local regulations regarding electrical and/or hazardous waste.
+
+The integrated Ridgeback charger will fully charge the internal lead-acid battery in a few hours. The charger will time out after 12 hours, so be sure to power cycle (by unplugging and re-plugging) the charger on a daily basis. Allow the battery to warm up to at least 10°C before charging.
+
+When the battery is running low on charge, the corner lights will start to flash yellow. This is your indication that the Ridgeback should be plugged in to charge soon.
+
+Please contact Clearpath Robotics for additional information about Ridgeback's batteries or for information about
+purchasing additional batteries.
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+Ridgeback contains several features to protect the safety of users and the integrity of the robot.
+
+:::caution
+
+Ridgeback is a powerful, heavy, fast moving robotic platform. Please read the following notices carefully.
+
+:::
+
+### General Warnings
+
+Ridgeback is a rugged and high-performance vehicle.
+For the safety of yourself and others, always conduct initial experiments and software development with the vehicle raised off the ground.
+Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any other solid flat structure having a height greater than 150 mm (6 inches)
+under Ridgeback to keep the wheels clear of the ground ("up on blocks").
+
+When starting out, favour slower wheel speeds.
+Ridgeback's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+### Stop Buttons {#ridgeback-stop-buttons}
+
+Ridgeback has four red Stop buttons, two on the front and two on the back. To engage Stop Mode, press
+any of the four Stop buttons once; you should see that all four corner LEDs are flashing red.
+To disengage Stop Mode, pull any engaged Stop buttons to release them, then press the Stop Reset button
+located below the rear-left Stop button; all corner LEDs should return to their original values.
+
+When in Stop mode the Ridgeback will not drive. The commands received during stop are not buffered;
+Ridgeback will always act on the latest commands received. This means that if motion commands are discontinued
+before the Stop button is released, the Ridgeback will not move. If the commands are continued,
+Ridgeback will move at the speed commanded once the Stop is released.
+
+Always ensure the Stop buttons are accessible at all times. Avoid mounting payloads that extend over the
+front or rear of Ridgeback and would occlude the Stop buttons.
+
+Note that the Ridgeback MCU board includes a breakout to allow an external motion-stop button/switch to be
+integrated by the end user, which could be used to engage/disengage Stop Mode.
+See [Optional External Motion Stop](integration_ridgeback.mdx#ridgeback-external-motion-stop)
+for details on adding an external motion-stop button/switch.
+
+### Electrical System
+
+Ridgeback is powered by two lead-acid (PbSO4) deep-cycle AGM batteries that are capable of delivering over 2000 W
+for short durations. This gives Ridgeback's motors their great performance; however, it is also enough power to
+cause severe bodily harm. Always use caution when operating Ridgeback to avoid personal injury or property damage.
+To ensure safety, please observe the following precautions:
+
+- Do not tamper with the battery terminals or wiring.
+- Do not tamper with the fuse panel, except to check and change the fuses, and to connect and disconnect the battery plug.
+- Always replace fuses with the same type and rating to ensure continued protection against risk of fires.
+- Consult Clearpath Robotics Support if you need to service the batteries.
+- Do not lay tools or other objects on top of the batteries.
+- Do not move the robot while charging the batteries.
+- Charge the battery only with the integrated charger installed by Clearpath Robotics.
+- Please dispose of the batteries properly or return them to Clearpath Robotics to do so.
+
+### Lifting and Transport
+
+- Ensure that Ridgeback's Stop Mode is engaged when transporting short distances and powered off when transporting longer distances.
+- Do not push the robot at more than 0.5 m/s (1.6 ft/s) or damage to the motor controls may occur.
+
+### Performance Considerations
+
+Included in Ridgeback are native software checks and limits to protect the robot.
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## Support {#ridgeback-support}
+
+
diff --git a/docs/robots/learning_platforms/_category_.json b/docs/robots/learning_platforms/_category_.json
new file mode 100644
index 000000000..1a7590254
--- /dev/null
+++ b/docs/robots/learning_platforms/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Learning Platforms",
+ "position": 4
+}
diff --git a/docs/robots/learning_platforms/turtlebot4.mdx b/docs/robots/learning_platforms/turtlebot4.mdx
new file mode 100644
index 000000000..2a92e737d
--- /dev/null
+++ b/docs/robots/learning_platforms/turtlebot4.mdx
@@ -0,0 +1,18 @@
+---
+title: TurtleBot 4 User Manual
+sidebar_label: TurtleBot 4
+sidebar_position: 1
+---
+
+import ComponentIntroductionTurtleBot4 from "/components/introduction_turtlebot4.mdx";
+
+
+
+:::note
+
+TurtleBot 4 documentation is hosted on a separate site. Use the link below
+to access the User Manual.
+
+[Link to TurtleBot 4 User Manual](https://turtlebot.github.io/turtlebot4-user-manual/)
+
+:::
diff --git a/docs/robots/legacy/_category_.json b/docs/robots/legacy/_category_.json
new file mode 100644
index 000000000..5de5d26c3
--- /dev/null
+++ b/docs/robots/legacy/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Legacy",
+ "position": 6
+}
diff --git a/docs/robots/legacy/pr2.mdx b/docs/robots/legacy/pr2.mdx
new file mode 100644
index 000000000..bb9636ba1
--- /dev/null
+++ b/docs/robots/legacy/pr2.mdx
@@ -0,0 +1,14 @@
+---
+title: PR2
+sidebar_label: PR2
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+This page provides links to the design files for the PR2 robot, designed by Willow Garage.
+
+- [PR2 Cable Drawings (27 MB)](https://pr2-docs.s3.us-east-2.amazonaws.com/pr2_cable_drawings.zip)
+- [PR2 Electrical Manufacturing Files (113 MB)](https://pr2-docs.s3.us-east-2.amazonaws.com/pr2_electrical_mfg_files.zip)
+- [PR2 Schematics (34 MB)](https://pr2-docs.s3.us-east-2.amazonaws.com/pr2_schematics.zip)
+- [PR2 CAD Files (11220 MB -- large!)](https://pr2-docs.s3.us-east-2.amazonaws.com/pr2_cad_files.zip)
diff --git a/docs/robots/outdoor_robots/_category_.json b/docs/robots/outdoor_robots/_category_.json
new file mode 100644
index 000000000..74c9bd8fe
--- /dev/null
+++ b/docs/robots/outdoor_robots/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Outdoor",
+ "position": 2
+}
diff --git a/docs/robots/outdoor_robots/husky/_category_.json b/docs/robots/outdoor_robots/husky/_category_.json
new file mode 100644
index 000000000..6d02f295b
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Husky",
+ "position": 2
+}
diff --git a/docs/robots/outdoor_robots/husky/a200/_category_.json b/docs/robots/outdoor_robots/husky/a200/_category_.json
new file mode 100644
index 000000000..79472b97e
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Husky A200",
+ "position": 1
+}
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/_category_.json b/docs/robots/outdoor_robots/husky/a200/integration_husky/_category_.json
new file mode 100644
index 000000000..e5f1838f9
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Integration",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/integration_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/integration_husky.mdx
new file mode 100644
index 000000000..103d81e89
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/integration_husky.mdx
@@ -0,0 +1,245 @@
+---
+title: Husky A200 Integration
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import ComponentTableHuskyOne from "/components/table_husky_1.mdx";
+import Support from "/components/support.mdx";
+
+
+
+To attach custom hardware to Husky, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+## Mechanical Mounting
+
+When determining mechanical mounting, you have two options, both of which are described below.
+
+- the "Standard" aluminum extrusion interface
+- the "PACS™" mounting system and associated kits
+
+### Mechanical, Standard
+
+A standard Husky is delivered with a 20 X 20 aluminum extrusion frame around the top of the user bay.
+This can be used for mouning sensors, lights, and other small attachments.
+We suggest using the following items to interface with this extrusion:
+
+| Description | CPR Item | Manufacturer | Manufacturer Item |
+| :------------------------------------------------ | :-------------: | :----------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 20 X 20 Aluminum Extrusion | | Misumi | [HFSB5-2020](https://us.misumi-ec.com/vona2/detail/110302683830/?HissuCode=HFSB5-2020&PNSearch=HFSB5-2020&searchFlow=results2type&KWSearch=HFSB5-2020) |
+| 20 X 20 Plasic End Cap | 000232 | Misumi | [HFC5-2020-B](https://us.misumi-ec.com/vona2/detail/110300440510/?HissuCode=HFC5-2020-B&PNSearch=HFC5-2020-B&searchFlow=results2type&KWSearch=HFC5-2020-B) |
+| Extrusion Corner Bracket, Blind | 000228 | Misumi | [SHBLBS5](https://us.misumi-ec.com/vona2/detail/110300439970/?HissuCode=SHBLBS5&PNSearch=SHBLBS5&searchFlow=results2type&KWSearch=SHBLBS5) |
+| Extrusion Stud, M5×0.8 | 001018 | Misumi | [HNTLSN5-5-12](https://us.misumi-ec.com/vona2/detail/110302369440/?HissuCode=HNTLSN5-5-12&PNSearch=HNTLSN5-5-12&searchFlow=results2type&KWSearch=HNTLSN5-5-12) |
+| Extrusion Nut, M5×0.8 | 026955 | Misumi | [SHNTAP5-5](https://us.misumi-ec.com/vona2/detail/110302247550/?HissuCode=SHNTAP5-5&PNSearch=SHNTAP5-5&searchFlow=results2type&KWSearch=SHNTAP5-5) |
+| Anchor, Cable Tie | 010439 | McMaster | [7582K65](https://www.mcmaster.com/7582K65/) |
+| Screw, M5×0.8, Stainless Steel (assorted lengths) | 023314 - 023324 | McMaster | [Many](https://www.mcmaster.com/screws/rounded-head-screws/hex-drive-rounded-head-screws/system-of-measurement~metric/metric-18-8-stainless-steel-button-head-hex-drive-screws/thread-size~m5/finish~passivated/) |
+| Nut, M5×0.8, Stainless Steel | 015175 | McMaster | [94205A240](https://www.mcmaster.com/94205A240/) |
+
+Misumi also offers a range of configurable products for this 20 X 20 extrusion that can help with your integration.
+
+### Mechanical, PACS™
+
+[PACS™](../../../../accessories/pacs) is a Clearpath Robotics standard.
+We add a grid of M5×0.8 holes onto the top plate of the robot.
+This grid of holes has a 80 mm X 80 mm spacing.
+You can create your own brackets to interface with these holes, or can use an existing Clearpath Robotics designed bracket.
+
+:::note
+
+Our [Sensors](../../../../accessories/sensors) and [Accessories](../../../../accessories/add-ons) pages indicate the required bracket for the particular attachment.
+
+:::
+
+Refer to the following pages for Husky brackets that can simplify your integration.
+
+- [Top Plate](kits/top_plate_husky.mdx)
+- [Weatherproofing Cover](kits/user_bay_cover_husky.mdx)
+- [Riser, Full](kits/riser_full_husky.mdx)
+- [Riser, Partial](kits/riser_partial_husky.mdx)
+- [Riser, Stiffener](kits/riser_stiffener_husky.mdx)
+- [Electronics Rack](kits/electronics_rack_husky.mdx)
+- [OutdoorNav Starter Kit](../../../../accessories/add-ons/outdoornav_starter_kit.mdx)
+
+---
+
+## Electrical Integration
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+
+### Data Connections
+
+Data connections (USB and Ethernet) are made to the Husky computer mounted in the user bay.
+In addition, the PCIe Gen3 x16 slot may be used to supply a GPU or other attachements, as necessary.
+Additionally, the user bay may be used for an Ethernet switch, when attaching multiple
+Ethernet payloads, or for a PoE power injector as required.
+
+### User Bay Power Connections
+
+The user bay power connections are capable of supplying:
+
+- VBAT (approximately 24-29 V, unregulated) fused at 5 A
+- 12 V fused at 7.5 A
+- 24 V fused at 3 A.
+
+In total, 282 W of power is available from these User Power breakouts.
+
+:::note
+
+You can order a upgrade for your Husky, that will add 480 W of power (VBAT fused at 20 A). Each terminal comes equipped with a
+removable connector into which your payload power leads may connect.
+
+:::
+
+:::note
+
+Husky UGVs with serial numbers lower than A200-0802 have different user power connections.
+These older robots have 5 V, 12 V, and 24 V supplies, all fused at 5A.
+Your Husky's serial number is shown on a sticker, attached to the right side of the robot.
+
+:::
+
+To connect to user power:
+
+1. Expose about 5 mm of bare wire from the payload power leads and twist the exposed wire on both leads.
+2. Take 2 Molex terminals from the spare parts kit provided and insert the exposed wire and crimp the
+ terminals, ensuring the wires are well secured inside the terminal, as shown below.
+3. Take 1 connector housing from the spare parts kit provided and insert the positive payload power lead
+ (red) into position 4, 5, or 6 of the connector until it locks into place. The positions numbers are
+ visible on the back of the plastic housing.
+4. Insert the negative payload power lead (black) into position 1, 2, or 3 of the connector until it locks
+ into place.
+
+
+
+
+ Crimping a wire
+
+
+
+
+
+ Inserting the crimped wires into the Molex connector
+
+
+
+When connecting payloads, be sure to observe correct polarity as marked on the inside of the user bay.
+Do not exceed the specified maximum current limit of each power rail; failure to do so may result in
+damage to Husky or your payload.
+
+For more technical information on the Molex power connectors, as well as their corresponding mating connectors,
+please visit the
+[Digi-Key WM23702-ND Product Page](https://www.digikey.ca/en/products/detail/molex/0039012065/930272?s=N4IgTCBcDaIOoFkwGYDsAGMBaAcgERAF0BfIA).
+
+### Serial Connection
+
+The pinout of the DE-9 connector is shown below.
+
+| | |
+| :-----------------------------------------------------------------------: | :------------------------: |
+| | |
+
+### External Motion Stop {#husky_external_stop}
+
+
+
+
+ E-stop Safety Loop connector inside the Husky user bay
+
+
+
+There is a connector labeled _E-STOP SAFETY LOOP_ that is inside the Husky's user bay.
+The connector has 2 contacts that lead to the Husky MCU circuit board.
+The MCU supplies +12 V on one of these leads, and monitors the voltage on the other lead.
+The MCU will place the Husky in a Stop state if the monitored line is below +12 V.
+
+Your robot may have a connector that adds a jumper wire between these 2 leads to complete the circuit;
+or your robot may have more Stop switches in series with this circuit.
+These additional components in series may be:
+
+- Emergency Stop buttons
+- [Wireless Stop receivers](../../../../accessories/add-ons/wireless_stop_system.mdx)
+- Relays or similar PLC components
+- Manipulator control cabinets
+
+:::info
+
+- The connector labeled _E-STOP SAFETY LOOP_ is a [Switchcraft EN3P2FX](https://www.switchcraft.com/en3-harsh-environment-panel-mount-2-contact-female/en3p2fx/)
+- The mating connector is a [Switchcraft EN3C2MX](https://www.switchcraft.com/en3-harsh-environment-cable-mount-2-contacts-male/en3c2mx/) ( _Clearpath Robotics item 008075_ )
+
+:::
+
+:::note
+
+This was an optional upgrade kit on Huskies built before March 2023.
+Clearpath Robotics still offers this upgrade kit to add an external motion stop to an older Husky.
+Contact [Support](#support) for details.
+
+:::
+
+:::caution
+
+This is a single channel Stop loop, being monitored by a microcontroller.
+When the microcontroller is in a Stop state; it will open relays which supply power to the Husky's motor controllers.
+These relays are not force guided or monitored.
+
+Please contact [Support](#support) if you need more information for your application's risk assessment.
+
+:::
+
+### MCU Debug LEDs
+
+The Husky MCU PCBA comes equipped with LEDs for debugging.
+They work as follows:
+
+- **D16: HEARTBEAT**: toggles every 500 ms when the main firmware loop on the MCU is running.
+- **D7: VBAT 20 A**: illuminated if the VBAT, 20 A fuse is good.
+ This LED will be off if the fuse is blown.
+- **D8: VBAT 5 A**: illuminated if the VBAT, 5 A fuse is good.
+ This LED will be off if the fuse is blown.
+- **D12: 12 V 7.5 A**: illuminated if the 12 V, 7.5 A fuse is good.
+ This LED will be off if the fuse is blown.
+- **D10: 24 V 3 A**: illuminated if the 24 V, 3 A fuse is good.
+ This LED will be off if the fuse is blown.
+
+:::note
+
+On older revisions of the Husky MCU PCBA, the labels are different, but the functionality is similar:
+
+- D5: HEARTBEAT
+- D2: VBAT, 5 A
+- D3: 12 V, 5 A
+- D4: 5 V, 5 A
+
+:::
+
+---
+
+## Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../../../accessories/computers/computers.mdx)
+- [Sensors](../../../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/_category_.json b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/_category_.json
new file mode 100644
index 000000000..cc3b026a7
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Kits",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/electronics_rack_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/electronics_rack_husky.mdx
new file mode 100644
index 000000000..6509fb95e
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/electronics_rack_husky.mdx
@@ -0,0 +1,29 @@
+---
+title: Electronics Rack
+sidebar_position: 7
+---
+
+## Sales Kits
+
+:::note
+
+These kits require a Husky with a Top Plate, and a Riser.
+Refer to the [Top Plate](top_plate_husky.mdx), [Full Riser](riser_full_husky.mdx) pages for further details.
+
+:::
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :------------------------------------------------- | :-------: | :------------------------------: |
+| Installation, Kit, Electronics Rack—Husky, 100, 2U | 026956 | 027233 |
+| Installation, Kit, Electronics Rack—Husky, 100, 4U | 026957 | 027234 |
+| Installation, Kit, Electronics Rack—Husky, 100, 6U | 026958 | 027235 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :----------------------------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1A | Beam—Rack, Upright Rails, 2U | [026959](/assets/pdf/clearpath_robotics_026959.pdf) | 4 |
+| 1B | Beam—Rack, Upright Rails, 4U | [026896](/assets/pdf/clearpath_robotics_026896.pdf) | 4 |
+| 1C | Beam—Rack, Upright Rails, 6U | [026960](/assets/pdf/clearpath_robotics_026960.pdf) | 4 |
+| 2 | Nut, Extrusion, Post-Assembly, Leaf Spring—M5×0.8 X 5.8, Stainless Steel | [026955](/assets/pdf/clearpath_robotics_026955-TDS1.pdf) | 16 |
+| 3 | Screw, Cap, Round Head—M5×0.8 X 8, Stainless Steel | 023316 | 16 |
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_full_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_full_husky.mdx
new file mode 100644
index 000000000..faf0d47b7
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_full_husky.mdx
@@ -0,0 +1,88 @@
+---
+title: Full Riser
+sidebar_position: 4
+---
+
+
+
+
+
+## Sales Kits
+
+:::note
+
+These kits require a Husky with a Top Plate.
+Refer to the [Top Plate](top_plate_husky.mdx) page for further details.
+
+:::
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :--------------------------------------------------- | :-------: | :------------------------------: |
+| Installation, Kit, Riser Full, With Holes—Husky, 100 | 027676 | 027677 |
+| Installation, Kit, Riser Full, With Holes—Husky, 200 | 027678 | 027679 |
+| Installation, Kit, Riser Full, With Holes—Husky, 300 | 027680 | 027681 |
+| Installation, Kit, Riser Full—Husky, 100 | 026948 | 027229 |
+| Installation, Kit, Riser Full—Husky, 200 | 026949 | 027230 |
+| Installation, Kit, Riser Full—Husky, 300 | 026950 | 027231 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :------------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1A | Plate—Integration, 670 X 590, With Holes | [027675](/assets/pdf/clearpath_robotics_027675.pdf) | 1 |
+| 1B | Plate—Integration, 670 X 590, Without Holes | [026888](/assets/pdf/clearpath_robotics_026888.pdf) | 1 |
+| 2A | Beam—93.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026921](/assets/pdf/clearpath_robotics_026921-TDS1.pdf) | 4 |
+| 2B | Beam—193.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026922](/assets/pdf/clearpath_robotics_026922-TDS1.pdf) | 4 |
+| 2C | Beam—293.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026923](/assets/pdf/clearpath_robotics_026923-TDS1.pdf) | 4 |
+| 2D | Beam—393.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026924](/assets/pdf/clearpath_robotics_026924-TDS1.pdf) | 4 |
+| 2E | Beam—493.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026925](/assets/pdf/clearpath_robotics_026925-TDS1.pdf) | 4 |
+| 2F | Beam—593.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026926](/assets/pdf/clearpath_robotics_026926-TDS1.pdf) | 4 |
+| 2G | Beam—693.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026927](/assets/pdf/clearpath_robotics_026927-TDS1.pdf) | 4 |
+| 2H | Beam—793.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026928](/assets/pdf/clearpath_robotics_026928-TDS1.pdf) | 4 |
+| 2I | Beam—893.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026929](/assets/pdf/clearpath_robotics_026929-TDS1.pdf) | 4 |
+| 2J | Beam—993.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026930](/assets/pdf/clearpath_robotics_026930-TDS1.pdf) | 4 |
+| 3 | Screw, Cap, Round Head—M5×0.8 X 14, Stainless Steel | 023319 | 8 |
+| 4 | Screw, Cap, Flat Head—M5×0.8 X 14, Stainless Steel | 023472 | 8 |
+
+## Tools
+
+- Hex Key, 3 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Fasten a Beam _(ID2)_ to the Husky's top plate using 2 screws _(ID3)_.
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 2
+
+Repeat this for the 3 remaining Beams.
+
+### Step 3
+
+Place the Riser's Plate on top of the Beams.
+The top of this Plate has the countersink features.
+The plate is symmetrical, so there is not a front / back side.
+
+### Step 4
+
+Fasten the Plate using 8 screws _(ID4)_
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_partial_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_partial_husky.mdx
new file mode 100644
index 000000000..fddaf5f52
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_partial_husky.mdx
@@ -0,0 +1,91 @@
+---
+title: Partial Riser
+sidebar_position: 5
+---
+
+
+
+
+
+## Sales Kits
+
+:::note
+
+These kits require a Husky with a Top Plate.
+Refer to the [Top Plate](top_plate_husky.mdx) page for further details.
+
+:::
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :------------------------------------------- | :-------: | :------------------------------: |
+| Installation, Kit, Riser Partial—Husky, 100 | 026932 | 027236 |
+| Installation, Kit, Riser Partial—Husky, 200 | 026933 | 027237 |
+| Installation, Kit, Riser Partial—Husky, 300 | 026934 | 027238 |
+| Installation, Kit, Riser Partial—Husky, 400 | 026935 | 027239 |
+| Installation, Kit, Riser Partial—Husky, 500 | 026936 | 027240 |
+| Installation, Kit, Riser Partial—Husky, 600 | 026937 | 027241 |
+| Installation, Kit, Riser Partial—Husky, 700 | 026938 | 027242 |
+| Installation, Kit, Riser Partial—Husky, 800 | 026939 | 027243 |
+| Installation, Kit, Riser Partial—Husky, 900 | 026940 | 027244 |
+| Installation, Kit, Riser Partial—Husky, 1000 | 026941 | 027245 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :------------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1 | Plate—Integration, 110 X 590 | [026887](/assets/pdf/clearpath_robotics_026887.pdf) | 1 |
+| 2A | Beam—93.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026921](/assets/pdf/clearpath_robotics_026921-TDS1.pdf) | 4 |
+| 2B | Beam—193.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026922](/assets/pdf/clearpath_robotics_026922-TDS1.pdf) | 4 |
+| 2C | Beam—293.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026923](/assets/pdf/clearpath_robotics_026923-TDS1.pdf) | 4 |
+| 2D | Beam—393.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026924](/assets/pdf/clearpath_robotics_026924-TDS1.pdf) | 4 |
+| 2E | Beam—493.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026925](/assets/pdf/clearpath_robotics_026925-TDS1.pdf) | 4 |
+| 2F | Beam—593.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026926](/assets/pdf/clearpath_robotics_026926-TDS1.pdf) | 4 |
+| 2G | Beam—693.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026927](/assets/pdf/clearpath_robotics_026927-TDS1.pdf) | 4 |
+| 2H | Beam—793.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026928](/assets/pdf/clearpath_robotics_026928-TDS1.pdf) | 4 |
+| 2I | Beam—893.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026929](/assets/pdf/clearpath_robotics_026929-TDS1.pdf) | 4 |
+| 2J | Beam—993.5 X 20 X 40, T-slot, 4X M5×0.8, Aluminum, Black | [026930](/assets/pdf/clearpath_robotics_026930-TDS1.pdf) | 4 |
+| 3 | Screw, Cap, Round Head—M5×0.8 X 14, Stainless Steel | 023319 | 4 |
+| 4 | Screw, Cap, Flat Head—M5×0.8 X 14, Stainless Steel | 023472 | 4 |
+
+## Tools
+
+- Hex Key, 3 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Fasten a Beam _(ID2)_ to the Husky's top plate using 2 screws _(ID3)_.
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 2
+
+Repeat this for the remaining Beam, adding the Beam to the other side of the robot, but in the same attachment row.
+
+### Step 3
+
+Place the Riser's Plate on top of the Beams.
+The top of this Plate has the countersink features.
+The plate is symmetrical, so there is not a front / back side.
+
+### Step 4
+
+Fasten the Plate using 4 screws _(ID4)_
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_stiffener_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_stiffener_husky.mdx
new file mode 100644
index 000000000..fe8205352
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/riser_stiffener_husky.mdx
@@ -0,0 +1,88 @@
+---
+title: Riser Stiffener
+sidebar_position: 6
+---
+
+
+
+
+
+## Sales Kits
+
+:::note
+
+These kits require a Husky with a Top Plate, and a Riser.
+Refer to the [Top Plate](top_plate_husky.mdx), [Full Riser](riser_full_husky.mdx), and [Partial Riser](riser_partial_husky.mdx) pages for further details.
+
+:::
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :----------------------------------------------------------------- | :-------: | :------------------------------: |
+| Installation, Kit, Attachment Tower Stiffener—Husky, Vertical, 144 | 027487 | 027482 |
+| Installation, Kit, Attachment Tower Stiffener—Husky, Vertical, 224 | 027488 | 027483 |
+| Installation, Kit, Attachment Tower Stiffener—Husky, Vertical, 304 | 027489 | 027484 |
+| Installation, Kit, Attachment Tower Stiffener—Husky, Vertical, 384 | 027490 | 027485 |
+| Installation, Kit, Attachment Tower Stiffener—Husky, Vertical, 464 | 027491 | 027486 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :----------------------------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1A | Beam, 45°—144 X 20 X 20, T-slot, Aluminum | [027492](/assets/pdf/clearpath_robotics_027492-TDS1.pdf) | 2 |
+| 1B | Beam, 45°—224 X 20 X 20, T-slot, Aluminum | [027479](/assets/pdf/clearpath_robotics_027479-TDS1.pdf) | 2 |
+| 1C | Beam, 45°—304 X 20 X 20, T-slot, Aluminum | [027493](/assets/pdf/clearpath_robotics_027493-TDS1.pdf) | 2 |
+| 1D | Beam, 45°—384 X 20 X 20, T-slot, Aluminum | [027494](/assets/pdf/clearpath_robotics_027494-TDS1.pdf) | 2 |
+| 1E | Beam, 45°—464 X 20 X 20, T-slot, Aluminum | [027495](/assets/pdf/clearpath_robotics_027495-TDS1.pdf) | 2 |
+| 2 | Screw, Cap, Socket Head—M5×0.8 X 8, Stainless Steel | 023149 | 4 |
+| 3 | Nut, Extrusion, Post-Assembly, Leaf Spring—M5×0.8 X 5.8, Stainless Steel | [026955](/assets/pdf/clearpath_robotics_027492-TDS1.pdf) | 2 |
+| 4 | Nut, Hex, Lock, Polymer Insert—M5×0.8 X 5, Stainless Steel | 010170 | 2 |
+
+## Tools
+
+- Hex Key, 3 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Decide if you are installing the Stiffener on the front or back side of the Riser.
+
+### Step 2
+
+Clip one of the nuts _(ID3)_ into the Riser's Beam, on the side where you will be installing the Stiffener.
+
+### Step 3
+
+Loosely attach the 45° Beam to the nut using a screw _(ID3)_.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 4
+
+Align the 45° beam with its mating hole on the Husky's Top Plate
+
+### Step 5
+
+Add a screw _(ID2)_ thru the Stiffener and Top Plate, with the screw's head facing up.
+
+### Step 6
+
+Tighten the joint by adding a hex nut _(ID4)_ to the bottom of the Husky's Top Plate.
+Torque the nut to 5 N·m.
+
+### Step 7
+
+Tighten the screw from Step 3.
+
+### Step 8
+
+Repeat steps 1 - 7 for the second Stiffener.
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/top_plate_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/top_plate_husky.mdx
new file mode 100644
index 000000000..144d4dce6
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/top_plate_husky.mdx
@@ -0,0 +1,81 @@
+---
+title: Top Plate
+sidebar_position: 2
+---
+
+
+
+
+
+## Sales Kits
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :-------------------------------------------- | :-------: | :------------------------------: |
+| Installation, Kit, Attachment Top Plate—Husky | 026942 | 027227 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :--------------------------------------------------------- | :-------------------------------------------------: | :------: |
+| 1 | Plate—670 X 590 | [026359](/assets/pdf/clearpath_robotics_026359.pdf) | 1 |
+| 2 | Angle, Bracket—564 X 25 X 25 | [007845](/assets/pdf/clearpath_robotics_007845.pdf) | 2 |
+| 3 | Screw, Cap, Socket Head—M5×0.8 X 14, Stainless Steel | 023152 | 4 |
+| 4 | Screw, Cap, Flat Head—M5×0.8 X 16, Stainless Steel | 023473 | 12 |
+| 5 | Nut, Hex, Lock, Polymer Insert—M5×0.8 X 5, Stainless Steel | 010170 | 12 |
+
+## Tools required
+
+- Wrench, 8 mm
+- Hex Key, 3 mm
+- Hex Key, 4 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Remove the old top plate or 20 X 20 aluminum extruision from the top of your Husky.
+
+### Step 2
+
+Remove the 4 screws on the sides of the Husky (2 per side).
+
+### Step 3
+
+Install the two Angle Brackets _(ID2)_ onto the bottom of the Plate _(ID1)_.
+The top side of the plate has the countersink features to the 12 mounting holes.
+Use the 12 screws _(ID4)_ and nuts _(ID5)_ to attach the Angle brackets to the Plate.
+Torque to 5 N·m
+
+:::tip
+
+Fasteners should be turned slowly to prevent galling of the stainless steel fasteners.
+Do not exceed 0.5 revolution per second when the fastener is nearly tight.
+
+:::
+
+### Step 4
+
+Place the asesmbly onto the Husky.
+The Husky's width may be larger than the assembly.
+It is easiest to start at the back of the Husky, and slowly rotate the assembly onto the Husky.
+You may need to loosen the 12 fastener connections from step 3 to get the assembly to fit onto the Husky.
+
+### Step 5
+
+Fasten the assembly on the Husky using 4 screws _(ID3)_.
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 6
+
+Re-torque any fasteners from step 3 that you loosened to ease installation of the assembly onto the Husky.
diff --git a/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/user_bay_cover_husky.mdx b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/user_bay_cover_husky.mdx
new file mode 100644
index 000000000..eae4fc009
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/integration_husky/kits/user_bay_cover_husky.mdx
@@ -0,0 +1,65 @@
+---
+title: User Bay Cover
+sidebar_position: 3
+---
+
+
+
+
+
+## Sales Kits
+
+:::note
+
+These kits require a Husky with a Top Plate.
+Refer to the [Top Plate](top_plate_husky.mdx) page for further details.
+
+:::
+
+| Description | Sales Kit | Installation Kit, With Fasteners |
+| :------------------------------------------------------------ | :-------: | :------------------------------: |
+| Installation, Kit, Cover, User Bay—Husky, Blank | 026947 | 027228 |
+| Installation, Kit, Cover, User Bay—Husky, Connectors | 027255 | 027254 |
+| Installation, Kit, Cover, User Bay—Husky, Fans and Connectors | 027194 | 027250 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :-------------------------------------------------- | :-------------------------------------------------: | :------: |
+| 1A | Plate—Connector Bulkhead, Blank | [026855](/assets/pdf/clearpath_robotics_026855.pdf) | 1 |
+| 1B | Plate—Connector Bulkhead, Connector Cutouts | [027256](/assets/pdf/clearpath_robotics_027256.pdf) | 1 |
+| 1C | Plate—Connector Bulkhead, Fan and Connector Cutouts | [027195](/assets/pdf/clearpath_robotics_027195.pdf) | 1 |
+| 2 | Gasket—Connector Bulkhead, Rubber | [029427](/assets/pdf/clearpath_robotics_029427.pdf) | 1 |
+| 3 | Screw, Cap, Round Head—M5×0.8 X 8, Stainless Steel | 023316 | 18 |
+| 4 | Washer—Ø5.3 X Ø10 X 2.36, Rubber | [029278](https://www.mcmaster.com/94733a413/) | 18 |
+| 5 | _(Optional)_ Fan Guard—60 mm | [011155](https://www.mcmaster.com/19155K3/) | 2 |
+
+## Tools
+
+- Hex Key, 3 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Place the Gasket _(ID2)_ on the Husky's Top Plate.
+
+### Step 2
+
+Place the Connector Plate _(ID1)_ on the Gasket.
+
+### Step 3
+
+Use 18 screws _(ID3)_ and washers _(ID4)_ to fasten the Connector Plate to the Husky.
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/husky/a200/maintenance_husky.mdx b/docs/robots/outdoor_robots/husky/a200/maintenance_husky.mdx
new file mode 100644
index 000000000..d5508a466
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/maintenance_husky.mdx
@@ -0,0 +1,275 @@
+---
+title: Husky A200 Maintenance
+sidebar_label: Maintenance
+sidebar_position: 5
+---
+
+import ComponentReplacingTireOrInnerTube from "/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx";
+import ComponentUpdatingPumaFirmware from "/components/maintenance/firmware_update_puma.mdx";
+import ComponentLeadAcidBatteryCare from "/components/maintenance/lead_acid_battery_care.mdx";
+import ComponentLeadAcidBatteryCareTips from "/components/maintenance/lead_acid_battery_care_tips.mdx";
+import ComponentBillOfMaterialsNote from "/components/maintenance/bill_of_materials_note.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+
+
+---
+
+## Common Replacement Items {#husky_maintenance_common_replacement_items}
+
+
+
+| Description | CPR Item | Manufacturer | Manufacturer Item | Distributor | Distributor Item |
+| :------------------------- | :------- | :---------------------- | :-------------------- | :---------- | :--------------- |
+| Battery | 005670 | Clearpath Robotics | - | - | - |
+| Battery Charger | 000597 | Clearpath Robotics | - | - | - |
+| Connector, Mini-fit-jr | 022207 | Molex | 39-01-2065 | Digi-Key | WM23702-ND |
+| Contact Crimp, Mini-fit-jr | 022207 | Molex | 40-13-0852 | Digi-Key | WM24935-ND |
+| Fuse, 3 A | 020411 | Littelfuse | 0287003.PXCN | Digi-Key | F4193-ND |
+| Fuse, 5 A | 006745 | Littlefuse | 0287005.PXCN | Digi-Key | F4197-ND |
+| Fuse, 7.5 A | 025899 | Littelfuse | 028707.5PXCN | Digi-Key | F4198-ND |
+| Fuse, 20 A | 025898 | Littelfuse | 0287020.PXCN | Digi-Key | F4201-ND |
+| Fuse, 30 A | 025896 | Littelfuse | 0299030.ZXNV | Digi-Key | F1036-ND |
+| MCU circuit board | 027104 | Clearpath Robotics | - | - | - |
+| Motor, standard | 005063 | Midwest Motion Products | S22-346F-24V GP52-079 | - | - |
+| Motor, high torque | 007449 | Midwest Motion Products | S22-346F-24V GP52-150 | - | - |
+| Tire | 000269 | Carlisle | 5100201 | - | - |
+| Tire's inner tube | 000435 | Carlisle | 323790 | - | - |
+
+---
+
+## Chassis
+
+Husky is an all-terrain robot, but it is not waterproof.
+Care should be taken that no part of the main chassis is ever submerged in water.
+When the chassis becomes wet or dirty, wipe it down with a damp cloth and dry with a towel.
+
+If water is suspected to have entered the Husky A200 chassis, remove the battery and allow Husky to fully dry
+for a minimum of 24 hours.
+
+:::note
+
+Clearpath Robotics offers a Waterproofing Kit for Husky.
+This includes a top cover for the user bay, sealed drivetrain bearings, and rubber foam tape on all the panel seams.
+
+:::
+
+---
+
+## Checking Drivetrain Health
+
+Depending on the environment in which the robot is used in and duty cycle,
+the robot drivetrain may require maintenance during its life. Maintenance
+activities can include gearhead replacement, tire tread replacement, motor
+brush replacement, belt replacement, bearing replacement, etc.
+
+It is recommended that the user perform an auditory inspection of the
+robot drivetrain once per month. Take note of any clicking, grinding or
+irregular skipping sounds while the robot is moving. Note that some clicking
+in the gearheads is normal during stops and starts, due to backlash between
+the gears.
+
+---
+
+## Wheels
+
+Tire pressure may change with temperature and should be checked monthly
+with a pressure gauge. Inspecting tires, releasing pressure, and inflating
+tires are completed through the tire's inflation stem.
+Tire pressure should not exceed 137 kPa (20 psi), and lower pressure may be desired based on terrain requirements.
+A monthly visual inspection of the tire treads is also recommended.
+Replacement wheel assemblies can be purchased from Clearpath Robotics and
+can be installed by the user.
+
+:::tip
+
+Husky's wheels can handle a range of different terrains, but work best when inflated to the proper pressure.
+Lower tire pressures, for example 68.5 kPa (10 psi), ensure better traction in rough and varied terrain, where rocks
+or other obstacles may be encountered. This has the adverse effect of lowering drivetrain efficiency and decreasing
+battery charge, so high pressures up to a maximum of 137 kPa (20 psi) should be used when driving on flat surfaces.
+
+Lower tire pressuses also reduce the effective diameter of the wheel, and will impact your odometry readings.
+Odometry is calculated using the average diameter of a tire inflated to 137 kPa (20 psi).
+
+:::
+
+---
+
+## Replacing Tire or Inner Tube
+
+
+
+---
+
+## Lead-Acid Battery Care
+
+Husky's default power supply is a sealed 24 V lead-acid battery (VRLA), providing 20 Ah of charge.
+These tips are intended to help keep your Husky Lead-Acid Battery in tip-top shape.
+With proper maintenance, the battery should maintain the majority of its capacity for hundreds of cycles.
+
+
+
+Your robot's battery charger works in 3 stages:
+
+1. Constant current charging
+2. Topping charge
+3. Float charge
+
+The bulk of the capacity (70%) is regained during the first stage.
+
+It is important to let the charger complete all 3 stages whenever possible, to help maintain the life of the battery.
+The initial stage will take 5 - 7 hours, and a complete charge may take up to 14 hours.
+
+
+
+
+
+
+
+---
+
+## Lithium Battery Care
+
+If your Husky has an upgrade to lithium batteries, note the required maintenance below.
+
+### Balancing Lithium Batteries
+
+The Husky's batteries must be balanced on a regular basis to ensure accurate
+feedback, consistent performance, and long life. If the batteries are
+allowed to fall out of balance, they will become unevenly loaded. This can
+lead to back-feeding between batteries, reduced charge-holding capacity
+for the system as a whole, and increased stress on both batteries.
+If the imbalance becomes severe enough, one of the system batteries
+will enter a protective state and disconnect itself from the system.
+Once the battery enters this state there is a limited time window to
+recover it. If that window expires the battery will become irreversibly
+damaged with no possibility of recovery.
+
+Battery balancing is a slow process that will occur automatically when
+the fully-charged batteries are held at their float voltage. Because the
+automatic charger will shut off when it determines that the batteries are
+fully charged, the system cannot be balanced using the autocharge dock.
+The manual charger must be used.
+
+To perform a "quick" balance, leave the robot plugged into the manual
+charger overnight. A quick balance is recommended at least once per week.
+A full balance of 24+ hours is recommended at least once per month.
+
+Contact Clearpath Robotics for assistance with recovering a battery that
+has entered a protective state.
+
+### Checking Lithium Battery Health
+
+A regularly-balanced battery system can be recharged thousands of times
+before degrading. Even with good battery maintenance, the battery will
+lose capacity over time. This results in reduced runtime and driving
+range for your Husky. This translates to reduced run-time and
+range. The robot will need to be recharged more frequently and overall
+system availability will be reduced.
+
+It is recommended that the system operator review runtime performance
+once per year to determine whether battery replacement is required.
+Runtime measurements should be taken immediately after a full balancing
+operation. Battery replacement is performed by Clearpath Robotics and
+is subject to battery availability. Replacement batteries may be
+purchased in advance and warehoused at Clearpath for future use.
+
+---
+
+## Replacing Fuses
+
+You Husky's MCU has fuses that can be changed through the rear battery access panel.
+The large battery input fuse is on the other side of the MCU, so you will need to remove Husky's metal panels to access this fuse.
+
+:::caution
+
+Refer to the white lettering on the circuit board for what rating of fuse to replace in the fuse holder.
+
+The [Common Replacement Items](#husky_maintenance_common_replacement_items) section of this page shows where you can purchase new fuses.
+
+:::
+
+
+ Click to expand
+
+
+
+
+ Husky's rear battery access
+
+
+
+
+
+
+
+
+ User power fuses
+
+
+
+
+
+
+
+
+ Main battery fuse
+
+
+
+
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+Customer updates of Husky firmware are not supported at this time. Contact [Support](#support) if
+Husky firmware updates are needed.
+
+### Motor Controller Firmware Update {#maintenance_husky_motor_controller_firmware}
+
+
+
+---
+
+## Support {#support}
+
+
+
+---
+
+## Future Work
+
+### Components that may require replacement
+
+- Battery
+- MCU
+- PUMA
+- Gearmotor
+- Drive Belt
diff --git a/docs/robots/outdoor_robots/husky/a200/troubleshooting_husky.mdx b/docs/robots/outdoor_robots/husky/a200/troubleshooting_husky.mdx
new file mode 100644
index 000000000..61bc338ff
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/troubleshooting_husky.mdx
@@ -0,0 +1,225 @@
+---
+title: Husky A200 Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 6
+---
+
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+ Rear of a Husky
+
+
+
+
+
+---
+
+## Status lights
+
+### `COMM` light on the rear panel is red
+
+A red COMM light means the Husky's computer to microcontroller serial connection is not established.
+This serial connection requires:
+
+- The computer to be on
+- The USB-Serial cable to be functioning properly.
+ A functioning cable will appear in Ubuntu as `/dev/ttyUSB` or `/dev/ttyACM`
+- The serial port has been given permissions in Linux.
+- The MCU's microcontroller is on.
+- The MCU has Husky's firmware installed on it.
+- Functioning connections from the USB-Serial cable to the MCU's microcontroller.
+ (soldered connectors, PCBA traces, microcontroller's soldered pins)
+
+If your robot was functioning recently, the most common causes are:
+
+- The robot's computer is not powered, or is still booting.
+ Wait 60 seconds after startup to see if the computer-to-MCU connection starts after the computer turns on.
+ If not, connect to the computer with SSH, or using a computer monitor to see if the computer is running.
+- The USB-Serial cable is not connected.
+ Check that the USB end is seated in the robot's computer.
+ Check that the DE-9 end is seated on it's [jack in the Husky user bay](user_manual_husky.mdx#onboard-computer-setup).
+- Someone has changed the robot.yaml configuration file. You can review the robot.yaml by running:
+ ```
+ nano /etc/clearpath/robot.yaml
+ ```
+
+### `COMM` light is yellow
+
+A yellow COMM light indicates that there is a functioning Serial connection between the robot's computer and MCU's microcontroller, but there is a ROS software error on the computer.
+The common causes for this error are:
+
+- The Husky's motion-stop button has been pressed. Twist the red button on the back of the Husky clockwise to release the motion-stop.
+ You can confirm the motion-stop state in ROS by running:
+ ```
+ rostopic echo /status
+ ```
+- The Husky's lockout keyswitch is in the _Locked_ position.
+ Use the included key to turn the lockout to the _Unlocked_ position.
+
+### `COMM` light flickers
+
+This frequently happens when the MCU is not receiving motion commands fast enough.
+Increase your published motion command in ROS to at least 10 Hz.
+
+```
+rostopic pub -r 10 /cmd_vel ...
+```
+
+:::note
+
+The maximum command frequency that Husky accepts is 50 Hz.
+
+:::
+
+### `ERR` light is on
+
+This light indicates a General Error.
+It is red when the Husky is in a motion-stop state, has insufficient battery voltage, or an if there is unspecified software error.
+
+### `STOP` status light is on
+
+1. Twist the red stop button at the back of the Husky.
+2. Confirm that the robot is not locked out.
+3. Confirm that all external stop devices are functioning, and that their related switches and relays are closed.
+ You may need to use a multimeter to test voltage between the external stop connector and each of these external stop switches.
+ Refer to the [External Stop](integration_husky/integration_husky.mdx#husky_external_stop) section for details.
+
+:::note
+
+You can confirm the motion-stop state in ROS by running:
+
+```
+rostopic echo /status
+```
+
+:::
+
+### Power button's blue light is not on
+
+The power button on the back of Husky has a blue light that turns on when the button is pressed, indicating that the Husky is receiving power.
+This light will turn on if the switch is receiving power, there is no sofware controlling it.
+For the button to turn on:
+
+1. The Husky needs to have a charged battery installed.
+2. The main fuse on the Husky's MCU needs to be functioning.
+3. The ribbon cable between the MCU and switch PCBA needs to be fully seated on both ends.
+4. The connector on the switch's cable needs to be fully seated on the switch's PCBA.
+
+We have not seen these connections fail, even in applications with lots of vibration.
+The most common fix for this issue is to check that battery is charged, and that it's power cable is seated in the Husky's MCU.
+
+### Battery indicator is flashing
+
+1. Battery voltage is too low for Husky to drive the motors.
+2. Charge the battery and try again.
+
+### Battery indicator only shows 50% charge with a fresh battery
+
+The battery indicator is controlled by the Husky MCU's microcontroller, based on a voltage measurement of the battery.
+The controls program was designed for a lithium battery.
+_24 V lithium batteries_ reach a peak voltage of 29 V.
+Our Standard _24 V lead-acid battery_ does not reach as high of a voltage, so the MCU's microcontroller thinks the battery is not fully charged.
+
+There is no way to change this behaviour on your Husky.
+
+---
+
+## Mobility
+
+### Husky experiences momentary drops in communication, or Husky's velocity has an inconsistent jumping motion
+
+It's possible the robot has reached the thermal limit, or current limit.
+The maximum current limits are set to 26 A, however, as the motors are only rated for 10.7 A continuous, anything above that will trigger the current limit eventually, the higher above this limit, the more quickly it will trigger.
+If you are unsure whether this is the case, feel free to contact \ with a rosbag of your system.
+
+:::note
+
+Clearpath Robotics also offers a high torque upgrade if more torque is required for your project.
+
+:::
+
+### Husky rolls on a slope
+
+Husky's wheels are always connected to the motors.
+When you send a motion command with `/cmd_vel`, the Husky's MCU subscribes to that message, and relays a command to the Husky's motor controllers.
+These motor controllers change the voltage across the DC brushed motors, causing a mechanical torque at the wheels.
+
+When you stop publishing to `/cmd_vel`, ROS starts publishing a default value to `/cmd_vel` of zero velocity.
+At this point, the motor controllers are not attempting to change the Husky's velocity using electrical power.
+When the Husky's velocity is near 0 m/s, the motor controllers will use the motor's copper windings as a resistor.
+This is why your Husky will roll on a slope, since the resistive torque of the copper windings is less than the gravitational force on the robot.
+
+:::note
+
+The `/twist_mux` topic controls to priority of `/cmd_vel` messages.
+
+:::
+
+:::tip
+
+If this amount of rolling is unacceptable, you can update the motor controller's firmware to a version that applies holding torque.
+The process to update the firmware is detailed on our [Husky Maintenance page](maintenance_husky.mdx#maintenance_husky_motor_controller_firmware).
+
+:::
+
+Your Husky will roll if:
+
+- The Husky's motion-stop button is pressed.
+- Husky's motor controllers are receiving a zero velocity command, rather than a small value like 0.01 m/s.
+- The MCU is not functioning.
+ This will appear as other issues, such as the status lights not illuminating.
+- The computer is not communicating with the MCU.
+ This will appear as a red COMM light on the rear panel.
+- A motor shaft is broken.
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../../accessories/sensors/sensors.mdx).
+
+### A ROS package isn't starting
+
+1. Verify the upstart logs, `/var/log/upstart/husky_core.log` to see if there are any error during upstart.
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/outdoor_robots/husky/a200/tutorials_husky.mdx b/docs/robots/outdoor_robots/husky/a200/tutorials_husky.mdx
new file mode 100644
index 000000000..a16e18464
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/tutorials_husky.mdx
@@ -0,0 +1,35 @@
+---
+title: Husky A200 Tutorials
+sidebar_label: Tutorials
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky.mdx";
+import ComponentTutorialLinks from "../../../../components/_tutorials_link.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Husky Overview
+
+### Introduction
+
+Husky is a rugged, outdoor-ready unmanned ground vehicle (UGV), suitable for research and rapid prototyping applications.
+These tutorials will assist you with setting up and operating your Husky.
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/husky).
+
+
+
+## Jetson Installation
+
+Refer to the [Jetson](../../../accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx) page for details on installing a Jetson in Husky.
+However, at present, ROS 2 software is not supported on Jetson in Husky.
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/husky/a200/user_manual_husky.mdx b/docs/robots/outdoor_robots/husky/a200/user_manual_husky.mdx
new file mode 100644
index 000000000..3e07db3df
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a200/user_manual_husky.mdx
@@ -0,0 +1,402 @@
+---
+title: Husky A200 User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky.mdx";
+import Support from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+
+
+## Introduction
+
+Husky is a rugged and easy-to-use unmanned ground robot for rapid prototyping and research applications.
+
+
+
+### Shipment Contents
+
+Your Husky shipment contains the following:
+
+- Clearpath Robotics Husky
+- 24 V Sealed Lead-Acid Battery Pack
+- Battery Door Cover
+- Battery Charger
+- Lockout Keys (2X)
+- Power Connectors (3X)
+
+If you purchased standard payload modules or custom integration services with Husky, then additional equipment will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Husky is built around a computer running Ubuntu (Intel-based computer or Jetson developer kit), paired with a 32-bit microcontroller MCU.
+The MCU handles power supply monitoring and motor control.
+The communication channel between the MCU and computer is a serial connection.
+
+#### Exterior Features
+
+The Husky exterior is shown below and includes:
+
+- Extruded aluminum mounting rail
+- User payload area, including user power panel
+- Front and rear bumper bars
+- Battery bay
+- Status panel
+- Power button
+- Motion Stop button and lockout
+
+
+
+
+ Husky exterior, front view
+
+
+
+
+
+
+ Husky exterior, rear view
+
+
+
+#### Status Panel
+
+The status panel is a display of LED indicators located on the rear of the chassis which provide information about the current status of Husky.
+The indicators are described in the table below.
+
+| Icon | Description |
+| :----------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| | **Battery Status** The four LED segments provide an approximate indication of the relative lifetime remaining in the battery. |
+| | **Communication Status** When green, Husky is receiving a stream of correctly-formatted motion commands, and is ready to drive. When yellow, Husky is receiving commands, but will not drive due to emergency stop or another error. When red, serial communications are currently timed-out. |
+| | **General Error Status** Illuminates red when Husky will not drive due to an error state. Such states include emergency stop, insufficient battery power, or an unspecified software error. |
+| | **Emergency Stop Status** Illuminates red when Husky will not drive due to the emergency stop being activated, either onboard or wireless (if available). |
+| | **Charge Indicator** Illuminates red when Husky user power is being supplied externally. |
+
+#### Buttons and Lockouts
+
+The silver button at the top of the Status Panel is used to power the Husky on and off. From the "off" state, pressing the button
+will cause the Husky to power on and a blue ring at the edge of the button will be illuminated. From the "on" state, pressing
+the button will cause the Husky to power off and the blue ring will no longer be illuminated.
+
+See [Stop button and Lockout](#husky-stop-button-and-lockout) for details of the Stop button and Lockout.
+
+#### Payloads
+
+Additional payloads such IMUs, lidars, cameras, GPS, manipulators and many more can be integrated with Husky, either as part of your Husky purchase or installed after receiving your Husky.
+You can find a list of supported packages and related documentation for payloads in this documention portal, under the [Computers](../../../accessories/computers/computers.mdx),
+[Sensors](../../../accessories/sensors/sensors.mdx), [Manipulators](../../../accessories/manipulators/manipulators.mdx), and [Accessories](../../../accessories/add-ons/add-ons.mdx) sections.
+In addition, refer to [Husky Integration](integration_husky/integration_husky.mdx) for details on how to integrate your own payload or how to integrate a payload kit from Clearpath Robotics.
+Each payload kit that ships from Clearpath Robotics comes with a custom mounting bracket and cabling for easy attachment to Husky.
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855, and is shown in the figure below.
+Husky's front is shown.
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+
+
+#### Robot Equations
+
+As a starting point, Clearpath Robotics recommends using the following relationship between wheel velocity and platform velocity:
+
+$$
+v=\cfrac{v_{r}+v_{l}}{2}
+$$
+
+$$
+\omega=\cfrac{v_{r}-v_{l}}{W}
+$$
+
+$v$ represents the instantaneous translational speed of the platform and $\omega$ the instantaneous rotational speed.
+$v_\{r\}$ and $v_\{l\}$ are the right and left wheel velocities, respectively.
+$W$ is the effective track of the robot, 0.555 m.
+
+### System Specifications
+
+| Specification | Measurement |
+| :----------------------------- | :----------------------------------------------------------------------- |
+| Dimension, Length | 990 mm |
+| Dimension, Width | 670 mm |
+| Dimension, Height | 390 mm |
+| Track Width | 550 mm |
+| Wheelbase Length | 512 mm |
+| Ground Clearance | 130 mm |
+| Mass | 50 kg |
+| Maximum Payload¹ | 75 kg |
+| All-terrain Payload² | 20 kg |
+| Speed, Maximum | 1 m/s |
+| Climb Grade | 45 ° |
+| Traversal Grade / Sideslope | 30 ° |
+| Operating Temperature, Minimum | -10 °C |
+| Operating Temperature, Maximum | 40 °C (not in direct sunlight) |
+| Operating Time, Average | 3 hours |
+| Operating Time, Standby | 8 hours |
+| Battery | 20 Ah @ 24 V, sealed lead-acid |
+| Battery Charger | Short-circuit, over-current, over-voltage and reverse voltage protection |
+| Charge Time | 10 hours |
+| User Power, 2021 and older | 5 V, 12 V, V-battery, each fused at 5 A |
+| User Power, 2022 and newer | 12 V @ 7.5 A, 24 V @ 3 A, VBAT @ 5 A |
+| Communication | RS-232, 115200 baud |
+| Wheel Encoders | 78,000 ticks/m |
+| Internal Sensing | Battery Status, Wheel Odometry, Motor Currents |
+| Environmental | IP44 (base Husky); IP30 (with computer); IP55 (with weatherproofing kit) |
+
+_¹Continuous operation on relatively flat terrain with wide turns._
+_²robot climbing 30° grade with high-mounted payload, or turning in place in high-friction conditions._
+
+
+
+
+
+---
+
+## Getting Started
+
+You are ready to go! This section details how to get Husky into action.
+To begin, place Husky "up on blocks" as described in the [Safety](#safety) section, making sure that the wheels are clear of the ground.
+
+For most Husky setups, there will be an Onboard Computer which is directly connected to the Husky and an Offboard Computer which is used to control Husky and gather data.
+These two computers must be set up to communicate with each other.
+
+### Onboard Computer Setup
+
+If you purchased an Onboard Computer from Clearpath Robotics with Husky, it is already installed, connected, and powered.
+If not, or to set up your own Onboard Computer, see the [Husky Tutorials](tutorials_husky.mdx).
+
+Note that the Onboard Computer must be connected to Husky's serial port, which is located in the user power panel accessible from the User Bay.
+
+
+
+
+ Husky's serial port
+
+
+
+The connector is a female DE-9, suitable for connection directly to a USB-serial adaptor or to a computer serial port via a straight-through modem cable (not a null modem cable).
+How you connect the Onboard Computer to Husky depends on whether the Onboard Computer has a dedicated serial port.
+Husky is delivered with a USB-serial adaptor.
+
+### Powering Up
+
+Husky comes with the battery fully charged and installed, but disconnected for safety during shipping.
+To reconnect the battery:
+
+- Ensure Husky's main power button is in the "off" position and that stop mode is activated.
+- Using curled index fingers to grip the battery door latches, press with thumbs on the latch buttons
+ and lift the battery door free of the chassis.
+- Carefully connect the battery plug to the mating connector in the fuse panel.
+ Ensure that it is firmly seated and clicks into place.
+ It will be difficult to connect it in the incorrect polarity.
+- Replace the battery door cover, ensuring that it clicks into place and is flush with the rear panel.
+
+
+
+
+
+To power on Husky, firmly press the power button located above the status panel.
+It will illuminate blue, and the status panel lights will show a brief test pattern.
+The `COMM` status light will turn red, as the computer is not yet communicating with Husky.
+
+The `STOP` status light will be red if the Stop button is pressed.
+If the Stop button is not pressed, press it and verify that the `STOP` light illuminates.
+Leave the platform in stop mode until it is successfully receiving commands, indicated by the `COMM` status light turning green or yellow.
+If a computer was purchased with Husky, it will be setup to interface automatically upon startup; 60-90 seconds after booting up, `COMM` status light will change from red to green (or yellow, depending on the stop mode status).
+This indicates that ROS is up on the computer and has established communications with the Husky base.
+
+### Network Configuration
+
+To get Husky connected to your local Wi-Fi network, you must first access the Onboard Computer using a wired connection to the robot.
+See the [Husky Tutorials](tutorials_husky.mdx) for details.
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Husky and powered on.
+If your purchased the Onboard Computer from Clearpath Robotics, your controller is already paired with your Husky.
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the
+[Husky Tutorials](tutorials_husky.mdx).
+
+To teleoperate Husky, first release the motion stop. Then, referring to the following images, press the enable button (either slow or fast mode) and use the left thumbstick to drive Husky.
+
+
+
+### Using ROS
+
+Robot Operating System (ROS) is an extensible framework for controlling and working with robotic systems.
+Clearpath Robotics recommends using ROS with your robot. If this is your first time using ROS, it is strongly
+recommended to run through our series of [ROS tutorials](../../../../ros) to learn
+the basics of ROS.
+
+### Battery Charging
+
+The battery shipped with Husky A200 may be charged outside the robot or while still inside of Husky.
+If charging while installed, you will need to open the access door to the battery area, and disconnect the battery from the MCU board.
+From there:
+
+1. Connect the DC output cable from the charger to the battery terminal connector.
+2. Plug the charger power cord into the charger and then into a wall receptacle.
+3. The LED light on the charger will illuminate red.
+4. When battery is fully charged, the LED light will turn green.
+5. Unplug the charger from the wall and then disconnect it from the battery.
+
+The battery charger shipped with Clearpath Robotics's lead-acid battery-powered products uses a two-state charge cycle.
+
+1. A fast, high current initial charge, until the battery voltage reaches 27.2 V.
+2. A topping charge, during which the battery charges at 27.2 V constant voltage.
+
+:::note
+
+Some older Husky chargers use a three-state charge cycle. For those older chargers, the LED light turns off
+(rather than green) when charging is complete.
+
+:::
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+Husky contains several features to protect the safety of users and the integrity of the robot.
+
+### General Warnings
+
+Husky is a rugged and high-performance robot.
+For the safety of yourself and others, always conduct initial experiments and software development with
+the robot raised off the ground. Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any
+other solid flat structure having a height greater than 150 mm under Husky to keep the wheels clear of the
+ground ("up on blocks").
+
+When starting out, favour slower wheel speeds. Husky's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+When Husky is operating, keep clear of the wheels, paying particular attention to the pinch hazard which exists between each wheel and the end of the corresponding bumper bar.
+
+### Stop Button and Lockout {#husky-stop-button-and-lockout}
+
+:::warning
+
+Ensure the Stop button is accessible at all times.
+Avoid mounting payloads that extend over the rear of Husky and would occlude the Stop button.
+
+:::
+
+The motion-stop function allows a person in the physical vicinity of the robot to halt its motion and prevent re-initiation of motion.
+Power supply to Husky's motor drivers is enabled by a normally-open relay, which is closed in series with the stop switch.
+This motion-stop system is intended for use in emergency situations.
+The motion stop system should not be used as the means of controlling robot motion during regular operation.
+
+When in stop mode, the status panel stop light will illuminate red and Husky will not drive.
+The commands received during stop mode are not buffered; Husky will always act on the latest commands received.
+This means that if the commands are stopped before the stop is released, the Husky will not move.
+If the commands are continued, Husky will move at the speed commanded once the stop is released.
+
+This "Stop" function can be asserted by pressing the red stop actuator present at the rear of the Husky, opposite the status panel, as shown in the following figure.
+The motion-stop function can be reset by twisting the depressed actuator until it returns to an extended position.
+There is no second "start" action required to reset the stop function.
+The robot may begin moving again immediately after the stop actuator has returned to its extended position.
+
+
+
+
+ Stop button and Lockout
+
+
+
+The lockout provides a way to secure Husky from performing any type of motion.
+When in lockout mode, the robot will still power on, but the motors will not drive.
+
+### Electrical System
+
+Husky is powered by a single 24 V sealed lead-acid battery, similar to the type found in electric wheelchairs, golf carts, and other devices.
+Husky's battery is capable of delivering 1800 W, similar to wall mains.
+This gives Husky's motors their great performance, however, it is also enough power to cause severe bodily harm.
+Please observe the following precautions:
+
+- Do not tamper with the plug attached to the battery.
+- Do not tamper with the fuse panel, except to check and change the fuses, and to connect and disconnect the battery plug.
+- Do not operate Husky without the battery door in place.
+ The battery is not restrained without the door, and will come loose, damaging the fuse panel.
+- Charge the battery only with the charger provided by Clearpath Robotics.
+- Please dispose of the batteries properly.
+
+### Lifting and Transport
+
+For the safety of users and to maximize the lifetime of Husky, please observe the following when manually transporting the robot:
+
+- Husky should be lifted by two persons, firmly gripping the front and rear bumper-bars.
+ The battery can be removed to lighten the load of a manual transport.
+- Ensure that Husky is in Stop mode when transporting short distances and powered off when transporting longer distances.
+- It is not advised to push Husky, as this can cause damage to the motors.
+
+### Performance Considerations
+
+Included in Husky are native software checks and limits to protect the robot.
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+The total current draw does not include the motors drivers; it is the current consumed by the MCU and user power ports.
+Husky's motors are rated to draw 10.7 A continuous, but they will spike to several times higher than this, particularly when traversing rough terrain and when turning on the spot.
+To reduce current draw, consider commanding wider-radius turns from your control software.
+
+The temperature is measured in the motor drivers and on the motor casings; the coils inside the motor casings cannot be measured.
+Therefore, it is important to note that the temperature measured on the motor casings is a lagging indicator of the temperature of the coils inside the casing.
+Be aware of the delay in heat propagation on the motors during heavy use.
+The thermal limit of the system is 50 °C, and the system will shut down if this limit is reached.
+Monitoring these fields over longer periods of operation will allow you to ensure that you are not putting excessive wear on Husky's motors.
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## Support
+
+
diff --git a/docs/robots/outdoor_robots/husky/a300/_category_.json b/docs/robots/outdoor_robots/husky/a300/_category_.json
new file mode 100644
index 000000000..1a33a72ca
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Husky A300",
+ "position": 2
+}
diff --git a/docs/robots/outdoor_robots/husky/a300/integration_husky/_category_.json b/docs/robots/outdoor_robots/husky/a300/integration_husky/_category_.json
new file mode 100644
index 000000000..e5f1838f9
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/integration_husky/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Integration",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/husky/a300/integration_husky/integration_husky.mdx b/docs/robots/outdoor_robots/husky/a300/integration_husky/integration_husky.mdx
new file mode 100644
index 000000000..76922074d
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/integration_husky/integration_husky.mdx
@@ -0,0 +1,683 @@
+---
+title: Husky A300 Integration
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky_a300.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import ComponentTableHuskyOne from "/components/table_husky_1.mdx";
+import Support from "/components/support.mdx";
+
+
+
+To attach custom hardware to Husky, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+## Mechanical Mounting
+
+Husky A300 is equipped with a [PACS™](../../../../accessories/pacs) top plate for
+mounting additional sensors and equipment.
+
+### PACS™ Mounting and Kits
+
+[PACS™](../../../../accessories/pacs) is a Clearpath Robotics standard, providing
+ a grid of M5X0.8 holes onto the top plate of the robot. This grid of holes has a 80 mm X 80 mm spacing.
+You can create your own brackets to interface with these holes, or can use an existing Clearpath
+Robotics bracket.
+
+:::note
+
+Our [Sensors](../../../../accessories/sensors) and [Add-ons](../../../../accessories/add-ons) pages
+indicate the required bracket for the particular attachment.
+
+:::
+
+### Cable Passthrough {#cable-passthrough}
+
+To maintain Husky's IP54 rating while allowing cables to pass between the external kits and internal
+electronics, Husky's top plate is provisioned with expansion plates for cable IP-rated cable
+systems. There are three expansion plates at the front and three at the rear of the top plate.
+
+
+
+
+ Top plate electrical expansion
+
+
+
+Users have two main options.
+
+1. Drill holes in the expansion plates and add appropriate IP-rated sealing solutions on a
+ cable-by-cable basis.
+1. Remove an expansion plate and replace it with a cable entry system, such as Icotek, which is
+ described in more detail below.
+
+#### Using the Icotek Cable Entry System
+
+The [Icotek Cable Entry System](https://www.icotek.com/en/products/cable-entry-systems)
+allows pre-terminated cables up to 65 mm in diameter to be routed into Husky A300 and be sealed with up
+to IP66 rated ingress protection (certified according to EN 60529 / UL50-E). In addition, the cable entry
+frames serve as strain relief on the cable (based on EN 62444).
+
+This cable system is based on a set of cable entry frames and grommets. Refer to the
+[demonstration video](https://www.youtube.com/watch?v=BQpOG0ptltE) for an overview of using the system.
+
+Supported cable entry frames are listed in the table below.
+
+| Part Number | Part Description | CPR Item Number | Retailer Link |
+| :---------- | :--------------- | :-------------- | :------------ |
+| KEL-ER-B4 V2A (48204.200) | IP66 2X2 cable entry frame | 031682 | [RS-Online](https://ca.rs-online.com/product/icotek/48204/72429054/) |
+| Gasket B (42452) | Gasket for KEL-ER-B4 | 031350 | [RS-Online](https://ca.rs-online.com/product/icotek/42452/72428604/) |
+| KEL-FG-ER-E2 (42345) | IP65 1X2 cable entry frame, 90° | 032777 | [RS-Online](https://ca.rs-online.com/product/icotek/42345/73389720/) |
+| Gasket E2 (42256) | Gasket for KEL-FG-ER-E2 | 032788 | Contact Icotek for local supplier |
+| DB 3X1 | M32 (54300) | Cable Gland Enclosure, 1X3 Small, 360⁰ | 028997 | [RS-Online](https://ca.rs-online.com/product/icotek/54300/74600584/) |
+
+Grommets are selected based on the size of the cable being passed through. A list of the most
+common grommets are listed in the table below. See also
+[full grommets product catalog](https://www.icotek.com/en/products/cable-grommets/kt-bk).
+
+| Part Number | Part Description | CPR Item Number | Retailer Link |
+| :---------- | :--------------- | :-------------- | :------------ |
+| Blank BK (41351) | Blank grommet | 031393 | [RS-Online](https://ca.rs-online.com/product/icotek/41351/72428519/) |
+| KT 1 BK (39943) | 1X Split grommet for 1-2 mm cable | N/A | [RS-Online](https://ca.rs-online.com/product/icotek/39943/72428434/) |
+| KT 2 BK (41302) | 1X Split grommet for 2-3 mm cable | 032027 | [RS-Online](https://ca.rs-online.com/product/icotek/41302/72428490/) |
+| KT 3 BK (41303) | 1X Split grommet for 3-4 mm cable | N/A | [RS-Online](https://ca.rs-online.com/product/icotek/41303/72428491/) |
+| KT 4 BK (41304) | 1X Split grommet for 4-5 mm cable | 032536 | [RS-Online](https://ca.rs-online.com/product/icotek/41304/72428492/) |
+| KT 5 BK (41305) | 1X Split grommet for 5-6 mm cable | N/A | [RS-Online](https://ca.rs-online.com/product/icotek/41305/72428493/) |
+| KT 6 BK (41306) | 1X Split grommet for 6-7 mm cable | 031394 | [RS-Online](https://ca.rs-online.com/product/icotek/41306/72428494/) |
+| KT 7 BK (41307) | 1X Split grommet for 7-8 mm cable | N/A | [RS-Online](https://ca.rs-online.com/product/icotek/41307/72428495/) |
+| KT 8 BK (41308) | 1X Split grommet for 8-9 mm cable | N/A | [RS-Online](https://ca.rs-online.com/product/icotek/41308/72428496/) |
+| KT 9 BK (41309) | 1X Split grommet for 9-10 mm cable | 031395 | [RS-Online](https://ca.rs-online.com/product/icotek/41309/72428497/) |
+| KT 10 BK (41310) | 1X Split grommet for 10-11 mm cable | 032535 | [RS-Online](https://ca.rs-online.com/product/icotek/41310/72428498/) |
+| KT 11 BK (41311) | 1X Split grommet for 11-12 mm cable | 031396 | [RS-Online](https://ca.rs-online.com/product/icotek/41311/72428499/) |
+| KT 2/6 BK (39905) | 2X Split grommet for 6-7 mm cable | 028994 | [RS-Online](https://ca.rs-online.com/product/icotek/39905/72428402/) |
+| KT 2/7 BK (39916) | 2X Split grommet for 7-8 mm cable | 031398 | [RS-Online](https://ca.rs-online.com/product/icotek/39916/72428413/) |
+| KT 2/8 BK (39918) | 2X Split grommet for 8-9 mm cable | 032028 | [RS-Online](https://ca.rs-online.com/product/icotek/39918/72428415/) |
+| KT 4/5 BK (39910) | 4X Split grommet for 5-6 mm cable | 031399 | [RS-Online](https://ca.rs-online.com/product/icotek/39910/72428407/) |
+| KT 4/6 BK (39933) | 4X Split grommet for 6-7 mm cable | 031400 | [RS-Online](https://ca.rs-online.com/product/icotek/39933/72428424/) |
+
+---
+
+## Electrical Integration
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+Some payloads also make use of signalling through the AUX inputs and outputs on the Main
+circuit board or through the Digital I/O pins on the computer.
+
+Refer to [Cable Passthrough](#cable-passthrough) for details on how to pass cables through
+Husky's top plate for external payloads.
+
+### Data Connections
+
+Data connections (USB and Ethernet) are made to the Husky computer mounted inside the chassis.
+These may be direct connections to the computer where ports are available or through USB hubs
+and network switches where expansion is required.
+
+### Main Circuit Board Connector Summary
+
+The Main circuit board provides a number of connections for power, fans, relays, GPIOs, auxiliary
+inputs and auxiliary outputs. These are summarized in the following table and described in more
+detail in the following sections.
+
+| MCU board label | MCU board connector | Mating connector | Crimp terminals | Crimping tool |
+| :--------------------------- | :---------------------------------- | :-------------------------------------------------------- | :----------------------------------------------------------- | :--------------- |
+| USER 1 - USER 8 | Molex 0039296088 | Molex 0039012080 | Molex 0039000140 (AWG 22-28) or Molex 0039000073 (AWG 18-24) | Molex 0638191000 |
+| EXP 1 - EXP 2 | Molex 1720650202 | Molex 1700010102 | Molex 1720630311 (AWG 14-16) or Molex 1720630312 (AWG 12) | Molex 2238631200 |
+| EXP CTRL | TE 3-794682-8 | TE 794617-8 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| AUX1 IN, AUX2 IN, AUX3 IN | TE 3-794682-6 | TE 794617-6 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| AUX1 OUT, AUX2 OUT, AUX3 OUT | TE 3-794682-8 | TE 794617-8 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| GPIO | TE 4-794680-6 | TE 1-794617-6 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| FAN 5 - FAN 8 | Molex 0705430003 | Molex 0050579404 | Molex 0016020103 (AWG 22-24) | Molex 0638118700 |
+| W ES (Wireless E-Stop) | TE 4-794682-0 | TE 1-794617-0 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| ES 3 - ES 8 (E-Stop) | TE 3-794682-4 | TE 794617-4 | TE 1-794606-1 (AWG 20-24) or TE 1-794607-1 (AWG 26-30) | TE 91391-1 |
+| SYS1 - SYS 2 | Molex 1720650204 | Molex 1700010104 | Molex 1720630311 (AWG 14-16) or Molex 1720630312 (AWG 12) | Molex 2238631200 |
+| SYS3 | Molex 1720650206 | Molex 1700010106 | Molex 1720630311 (AWG 14-16) or Molex 1720630312 (AWG 12) | Molex 2238631200 |
+| SYS4 | Molex 0039281023 | Molex 0039012020 | Molex 0039000140 (AWG 22-28) or Molex 0039000073 (AWG 18-24) | Molex 0638191000 |
+
+### Power Connections
+
+#### User Power Connections {#user-power-connections}
+
+The Main circuit board provides eight connectors, labelled USER 1 through USER 8, for user power.
+
+User power is divided into four power rails and the power for each rail is shared
+across each of the 8 connectors. The maximum (aggregate) current available on each power rail is
+outlined in the table below.
+
+| User Power Rail | Maximum (Aggregate) Current |
+| :-------------------------- | :-------------------------- |
+| 12 V Rail A | 5 A |
+| 12 V Rail B | 5 A |
+| 24 V | 5 A |
+| VBAT (24-29 V, unregulated) | 5 A |
+
+:::safety-warning
+
+**Do not exceed the specified maximum current limit of each power rail.**
+
+Failure to do so may result in damage to your payload.
+
+:::
+
+##### User Power Pin Mapping
+
+The pinout for each of the eight connectors (USER 1 - USER 8) is illustrated below.
+
+| USER connector pin | Function |
+| :----------------- | :------- |
+| 1 | 12 V (Rail B) |
+| 2 | 12 V (Rail A) |
+| 3 | 24 V |
+| 4 | VBAT (24-29 V, unregulated) |
+| 5 | GND |
+| 6 | GND |
+| 7 | GND |
+| 8 | GND |
+
+##### Making Cables to Connect to User Power
+
+Connecting to user power requires the use of a Molex connector and compatible crimp terminals.
+To create these cables, follow the steps below.
+
+1. Expose about 5 mm of bare wire from the payload power leads and twist the exposed wire on both leads.
+2. Take 2 Molex terminals from the spare parts kit provided and insert the exposed wire and crimp the
+ terminals, ensuring the wires are well secured inside the terminal, as shown below.
+3. Take 1 connector housing from the spare parts kit provided and insert the positive payload power lead
+ (red) into position 1, 2, 3 or 4 of the connector until it locks into place. The positions numbers are
+ visible on the back of the plastic housing.
+4. Insert the negative payload power lead (black) into position 5, 6, 7, or 8 of the connector until it locks
+ into place.
+
+
+
+
+ Crimping a wire
+
+
+
+
+
+ Inserting the crimped wires into the Molex connector
+
+
+
+For more technical information on the Molex power connectors, as well as their corresponding mating connectors,
+please visit the
+[Digi-Key WM3703-ND Product Page](https://www.digikey.ca/en/products/detail/molex/0039012080/61382).
+
+##### Software Control of User Power Rails {#user_power_control}
+
+User power can be enabled or disabled through ROS by publishing to `/a300_#####/platform/mcu/cmd_user_power` ROS topic.
+
+To disable user power, run:
+
+```
+ros2 topic pub --once /a300_#####/platform/mcu/cmd_user_power std_msgs/msg/Bool '{data: false}'
+```
+
+To enable user power, run:
+
+```
+ros2 topic pub --once /a300_#####/platform/mcu/cmd_user_power std_msgs/msg/Bool '{data: true}'
+```
+
+:::note
+
+User power is enabled by default shortly after the robot first powers up,
+regardless of its state when the robot was powered off.
+
+:::
+
+
+
+#### High Power Expansion Kit {#high-power-expansion-kit}
+
+:::note
+
+The optional High Power Expansion Kit can purchased at the time of your original Husky
+order, referring to CPR Item 032001. Field installation is not supported at present.
+
+:::
+
+:::note
+
+When using the optional High Power Expansion Kit while operating in environments with
+inclines of 5° (or more) AND with a payload of 50 kg (or more), a 4-battery or
+6-battery configuration is recommended. Using a 2-battery configuration may provide
+insufficient power in the worst case. Contact [Support](#support) for additional details.
+
+:::
+
+Some high power payloads, such as manipulators, require more power than can be provided
+through the user power connectors. The optional High Power Expansion Kit provides access to
+VBAT at 40 A. It also includes two contactors for enabling and disabling power to the payload.
+
+##### Creating a Mating Cable
+
+To use the High Power Expansion Kit, if present, the user can begin by creating a mating
+cable. #10 AWG is recommended for cable routing within the chassis, such as to a manipulator
+control board. #8 AWG is recommended for cable routing outside the chassis, noting that
+#8 AWG is acceptable in an exposed cable for 40 A, per UL 1740. The mating cable will
+connect to the yellow SB50 connector in left-rear of the chassis, under the top plate.
+
+:::note
+
+Always observe local laws and electrical standards valid to your region when building cables.
+
+:::
+
+:::note
+
+When building cables, be sure to consult the manufacturer documentation for full details
+on proper crimping.
+
+:::
+
+| Description | Vendor Part | CPR Part Number |
+| :----------- | :----------------- | :-------------- |
+| Mating connector | [Anderson 992G5-BK](https://www.digikey.ca/en/products/detail/anderson-power-products-inc/992G5-BK/10650433) | 022554 |
+| Crimps, #8 AWG | [Anderson 5952-BK](https://www.digikey.ca/en/products/detail/anderson-power-products-inc/5952-BK/10650106) | 017281 |
+| Crimps, #10-12 AWG | [Anderson 5953-BK](https://www.digikey.ca/en/products/detail/anderson-power-products-inc/5953-bk/10650410) | 022562 |
+| Crimping tool | [Anderson 1309G4](https://www.digikey.ca/en/products/detail/anderson-power-products,-inc./1309G4/10650073) | N/A |
+
+##### Replacing the Fuse
+
+If you need to replace the fuse, use a [Littlefuse F6792-ND](https://www.digikey.ca/en/products/detail/littelfuse-inc/142-5631-5402/2515916)
+as the replacement.
+
+##### On/Off Control via Software
+
+The High Power Expansion Kit output is controlled through software by publishing to the ROS topic `/a300_#####/platform/mcu/cmd_high_power`,
+similar to [Software Control of User Power Rails](#user_power_control).
+
+:::note
+
+The High Power Expansion Kit output is always disabled when the system powers up.
+The user must enable the output, via the ROS topic above, each time after the system powers up.
+
+:::
+
+### AUX Inputs
+
+The Main circuit board provides 3 auxilliary inputs (AUX1 IN, AUX2 IN, AUX3 IN) that
+allow external payloads to provide inputs to the robot. Each of the three auxilliary
+inputs can be driven by one of the following:
+
+- a 12 V input
+- a 24 V input
+- a push button or switch
+
+In turn, the state of the input can be read from the ROS topic `/a300_#####/platform/mcu/status/aux_inputs`.
+The AUX inputs are active low and are mapped to the ROS message bits as follows:
+
+- AUX1 IN: bit 0
+- AUX2 IN: bit 1
+- AUX3 IN: bit 2
+
+| AUX Input | Payload State | `/a300_#####/platform/mcu/status/aux_inputs` Value |
+| :------------------- | :------------------------------------------------------------------------------------ | :---------------------------------------- |
+| AUX1 IN | 24 V on OR 12 V on OR button pressed 24 V off AND 12 V off AND button not pressed | bit 0 reads as '0' bit 0 reads as '1' |
+| AUX2 IN | 24 V on OR 12 V on OR button pressed 24 V off AND 12 V off AND button not pressed | bit 1 reads as '0' bit 1 reads as '1' |
+| AUX3 IN | 24 V on OR 12 V on OR button pressed 24 V off AND 12 V off AND button not pressed | bit 2 reads as '0' bit 2 reads as '1' |
+
+#### AUX Input Pin Mapping
+
+The pinout for each of the three connectors (AUX1 IN, AUX2 IN, AUX3 IN) is illustrated below.
+
+| AUX IN connector pin | Function |
+| :------------------- | :------- |
+| 1 | 24 V In |
+| 2 | 12 V In |
+| 3 | Button/Switch In (3.3 V) |
+| 4 | 24 V Return |
+| 5 | 12 V Return |
+| 6 | GND |
+
+#### AUX Input Example #1
+
+Consider the example where AUX2 IN has a 12 V supply connected to pins 2 and 5,
+with the remaining pins unconnected.
+
+Monitor the input reading in ROS.
+
+```
+ros2 topic echo /a300_#####/platform/mcu/status/aux_inputs
+```
+
+| Action | `/a300_#####/platform/mcu/status/aux_inputs` value | Bit 2 Explanation | Bit 1 Explanation | Bit 0 Explanation |
+| :----- | :------------ | :---------------- | :---------------- | :---------------- |
+| Begin with the 12 V supply turned off | 7 (8b00000111) | '1' since AUX3 IN is not connected | '1' since 12 V supply is off | '1' since AUX1 IN is not connected |
+| Turn the 12 V power supply on | 5 (8b00000101) | '1' since AUX3 IN is not connected | '0' since 12 V supply is on | '1' since AUX1 IN is not connected |
+| Turn the 12 V supply off | 7 (8b00000111) | '1' since AUX3 IN is not connected | '1' since 12 V supply is off | '1' since AUX1 IN is not connected |
+
+#### AUX Input Example #2
+
+Consider the example where AUX1 IN has a 24 V supply connected to pins 1 and 4,
+AUX2 IN has a 12 V supply connected to pins 2 and 5, and AUX3 IN has a push button
+connected to pin 3.
+
+| Action | `/a300_#####/platform/mcu/status/aux_inputs` value | Bit 2 Explanation | Bit 1 Explanation | Bit 0 Explanation |
+| :----- | :------------ | :---------------- | :---------------- | :---------------- |
+| Begin with 12 V supply turned off, the 24 V supply off, and the button not pressed | 7 (8b00000111) | '1' since button is not pressed | '1' since 12 V supply is off | '1' since 24 V supply is off |
+| Turn the 24 V power supply on | 6 (8b00000110) | '1' since button is not pressed | '1' since 12 V supply is off | '0' since 24 V supply is on |
+| Turn the 12 V supply on | 4 (8b00000100) | '1' since button is not pressed | '0' since 12 V supply is on | '0' 24 V supply is on |
+| Press and hold the button | 0 (8b00000000) | '0' since button is pressed | '0' since 12 V supply is on | '0' 24 V supply is on |
+
+### AUX Outputs
+
+The Main circuit board includes three user-controlled outputs (AUX1 OUT, AUX2 OUT, AUX3 OUT)
+that can be controlled by publishing to the `/a300_#####/platform/mcu/cmd_aux_outputs` ROS topic.
+To enable the AUX outputs, simply
+publish a single message with the appropriate bits set to 1 to turn the output on and 0 to turn
+it off. The state does not persist so new commands will need to keep the bit enabled as well.
+The AUX outputs are mapped to the ROS message bits as follows:
+
+- AUX1 OUT: bit 0
+- AUX2 OUT: bit 1
+- AUX3 OUT: bit 2
+
+#### Aux Output Examples
+
+To disable all AUX outputs:
+
+```
+rostopic pub /a300_#####/platform/mcu/cmd_aux_outputs std_msgs/UInt8 "data: 0"
+```
+
+To enable all AUX outputs:
+
+```
+rostopic pub /a300_#####/platform/mcu/cmd_aux_outputs std_msgs/UInt8 "data: 7"
+```
+
+To enable just the AUX3 output:
+
+```
+rostopic pub /a300_#####/platform/mcu/cmd_aux_outputs std_msgs/UInt8 "data: 4"
+```
+
+#### Aux Output Pin Mapping
+
+Each of the AUX outputs is an 8-pin connector with pin mapping as outlined below. The output
+value is available in several modes:
+
+- MOSFET outputs (x2)
+- Normally open relay
+- Normally closed relay
+
+| AUX OUT connector pin | Function | Output when corresponding `cmd_aux_outputs` bit is '0' | Output when corresponding `cmd_aux_outputs` bit is '1' |
+| :-------------------- | :------- | :------------------------------------------- | :------------------------------------------- |
+| 1 (AUX_24V) | 24 V output, fused at 3 A, available for use with relay | 24 V | 24 V
+| 2 (GND) | GND | GND | GND |
+| 3 (AUX_RELAY_NC) | Normally closed relay pin | Connected to AUX_RELAY_COMMON | Floating |
+| 4 (AUX_MOSFET2) | MOSFET #2 DRAIN | GND | Floating |
+| 5 (GND) | GND | GND | GND |
+| 6 (AUX_RELAY_COMMON) | Input that gets connected to AUX_RELAY_NC or AUX_RELAY_NO | Connected to AUX_RELAY_NC | Connected to AUX_RELAY_NO |
+| 7 (AUX_RELAY_NO) | Normally open relay pin | Floating | Connected to AUX_RELAY_COMMON |
+| 8 (AUX_MOSFET1) | MOSFET #1 DRAIN | GND | Floating |
+
+### General Purpose Inputs and Outputs (GPIO)
+
+The Main circuit board includes four general purpose inputs and four general purpose
+outputs, which are all connected to the 16-pin GPIO connector. All GPIOs are at the
+3.3 V logic level. General purpose inputs are readable from the
+`/a300_#####/platform/mcu/status/gp_inputs` ROS topic.
+Publishing to the ROS `/a300_#####/platform/mcu/cmd_gp_outputs` topic controls the general purpose outputs.
+
+#### General Purpose Input Pin Mapping
+
+| GPIO connector pin | Function | `gp_inputs` value when driven at 0 V | `gp_inputs` value when driven at 3.3 V |
+| :----------------- | :------- | :----------------------------- | :------------------------------- |
+| 5 | GP In 1 | Bit 0 is '0' | Bit 0 is '1' |
+| 6 | GP In 2 | Bit 1 is '0' | Bit 1 is '1' |
+| 7 | GP In 3 | Bit 2 is '0' | Bit 2 is '1' |
+| 8 | GP In 4 | Bit 3 is '0' | Bit 3 is '1' |
+| 13 | GND | N/A | N/A |
+| 14 | GND | N/A | N/A |
+| 15 | GND | N/A | N/A |
+| 16 | GND | N/A | N/A |
+
+#### General Purpose Output Pin Mapping
+
+| GPIO connector pin | Function | Corresponding bit in `cmd_gp_outputs` | Output value when set to '0' | Output value when set to '1' |
+| :----------------- | :------- | :--------------------------- | :--------------------------- | :--------------------------- |
+| 1 | GP Out 1 | 0 | 0 V | 3.3 V |
+| 2 | GP Out 2 | 1 | 0 V | 3.3 V |
+| 3 | GP Out 3 | 2 | 0 V | 3.3 V |
+| 4 | GP Out 4 | 3 | 0 V | 3.3 V |
+| 9 | GND | N/A | GND | GND |
+| 10 | GND | N/A | GND | GND |
+| 11 | GND | N/A | GND | GND |
+| 12 | GND | N/A | GND | GND |
+
+### Fan Expansion
+
+The Main circuit board has support for four additional 12 V brushless 4-wire PWM fans,
+one fan at each of FAN 5, FAN 6, FAN 7, and FAN 8. (FAN 1, FAN 2, FAN 3, and FAN 4 are
+reserved for internal use.) Examples of supported fans include
+[CFM-8025BG-170-517-22](https://www.digikey.ca/en/products/detail/cui-devices/CFM-8025BG-170-517-22/16581761)
+and
+[9GA0812P4J001](https://www.digikey.ca/en/products/detail/sanyo-denki-america-inc/9GA0812P4J001/6192305).
+
+The pinout for each fan is:
+
+| Pin | Function / Value |
+| :-- | :--------------- |
+| 1 | 12 V |
+| 2 | GND |
+| 3 | Tachometer (output from fan) |
+| 4 | PWM (input to fan, 3.3 V) |
+
+The speed of each fan can be controlled by publishing to the `/a300_#####/platform/mcu/cmd_fans` topic in ROS.
+
+The speed of each fan can be monitored by reading the `/a300_#####/platform/mcu/status/fans` topic in ROS.
+
+In both cases, the fan value is in the range from 0 (not spinning) to 255 (max speed).
+
+:::info
+
+Fans require spool up time on startup. Setting a fan to a very low value may result in the fan not rotating.
+The user must experiment with the values to find the corresponding minimum speed at which the fan can be started
+and operated.
+
+:::
+
+### Wireless Emergency Stop {#wireless-stop}
+
+A wireless dual-channel emergency stop can be added to Husky so that the
+emergency stop can be invoked remotely (either through a button press
+or when the remote unit is out of range), in addition to the two built-in
+Emergency Stop Buttons. Refer to the [User Manual](../user_manual_husky#wireless-estop-bypass)
+for details on how the Wireless Emergency Stop can be bypassed
+in certain debugging scenarios.
+
+The Wireless Emergency Stop can be connected to Husky on the Main circuit
+board at the "W ES" connector, based on the pinout below.
+
+| W ES Pin | Function / Value |
+| :------- | :--------------- |
+| 1 | 24 V (fused at 3 A) |
+| 2 | CAN High: combined with CAN Low, connected to the CAN2 pins on the MCU; see additional notes below |
+| 3 | Reset In: Pull to GND for at least 100 ms to restart the robot after all emergency stops have been cleared; equivalent to pressing the Restart Button on Husky |
+| 4 | Channel 1 Out (24 V): normally connected to Channel 1 In; disconnect to trigger an emergency stop |
+| 5 | Channel 1 In |
+| 6 | GND |
+| 7 | CAN Low |
+| 8 | GND |
+| 9 | Channel 2 Out (24 V): normally connected to Channel 2 In; disconnect to trigger an emergency stop |
+| 10 | Channel 2 In |
+
+#### CAN Bus Connection
+
+The CAN High and CAN Low pins are connected to the CAN2 bus of the system, shared with the battery
+and wireless charger subsystems.
+
+The CAN2 bus is accessible on the computer as a linux socket under `can1` at a bitrate of 250000.
+
+#### Receiver Installation
+
+In addition to the electrical integration noted above, the wireless receiver will normally
+require mechanical mounting inside the Husky, along with external mounting of an antenna.
+Refer to [Wireless Stop receivers](../../../../accessories/add-ons/wireless_stop_system.mdx)
+and [Cable Passthrough](#cable-passthrough) for additional details.
+
+### External Emergency Stop {#husky_external_stop}
+
+In addition to the two built-in Emergency Stop Button and in addition to the
+optional Wireless Emergency Stop, six additional emergency stop inputs are available
+on the Main circuit board (ES3 - ES8). By default, each of these are wired with a bypass
+connector. However, it is possible to remove a bypass connector and replace it with
+a connection to a device such as:
+
+- Emergency Stop buttons
+- [Wireless Stop receivers](../../../../accessories/add-ons/wireless_stop_system.mdx)
+- Relays or similar PLC components
+- Manipulator control cabinets
+
+The pinout for ES3 - ES8 is shown below.
+
+| ESx Pin | Function / Value |
+| :------ | :--------------- |
+| 1 | Channel 1 Out (24 V): normally connected to Channel 1 In; disconnect to trigger an emergency stop |
+| 2 | Channel 1 In |
+| 3 | Channel 2 Out (24 V): normally connected to Channel 2 In; disconnect to trigger an emergency stop |
+| 4 | Channel 2 In |
+
+
+### Computer Power
+
+Three connectors are provided for powering computers, including GPUs: SYS1, SYS2, and SYS3. Collectively,
+they provide up to 400 W of power at 12 V.
+
+#### SYS1 / SYS2 Pinouts
+
+| Pin | Function / Value |
+| :-- | :--------------- |
+| 1 | 12 V |
+| 2 | 12 V |
+| 3 | GND |
+| 4 | GND |
+
+#### SYS3 Pinouts
+
+| Pin | Function / Value |
+| :-- | :--------------- |
+| 1 | 12 V |
+| 2 | 12 V |
+| 3 | 12 V |
+| 4 | GND |
+| 5 | GND |
+| 6 | GND |
+
+### Other System Power
+
+SYS4 is used to power the internal network switch and
+provides up to 60 W of power at 12 V.
+
+#### SYS4 Pinouts
+
+| Pin | Function / Value |
+| :-- | :--------------- |
+| 1 | 12 V |
+| 2 | GND |
+
+### Debug LEDs
+
+A number of Debug LEDs are available for helping to debug system status. Their function is
+outlined below.
+
+#### Common Core Debug LEDs
+
+- **D6: USB 5V**: Solid green if a USB cable is plugged in and used to power the board
+- **D7: 3.3V**: Solid green when the 3.3 V power rail is operational; else off
+- **D9: DBG/CON**: For future use
+- **D11: HB/ERR**: Heartbeat that toggles (red/off) every 500 ms when the main firmware loop is running; solid on or off indicates an error
+
+#### DC/DC Debug LEDs
+
+- **D3: V OUT**: Solid green when the output is operational; else off
+
+#### Motor Controller LEDs
+
+- **5V0**: Solid green when the 5 V power rail is operational; else off
+- **3V3**: Solid green when the 3.3 V power rail is operational; else off
+- **MTR_FAULT**: Solid red when a motor fault is detected; else off
+- **ERROR**: Toggles (red/off) every 500 ms when a motor control error is detected; else off
+- **DBG2**: For future use
+- **DBG1**: Heartbeat that toggles (green/off) every 500 ms when the firmware loop is running; solid on or off indicates an error
+
+#### Main Circuit Board Debug LEDs
+
+- **D2**: UVB FLT: User power VBAT fault: red if the user battery rail is not enabled or if there has been a fault such as an overcurrent or over temperature event; else off
+- **D3**: U24 FLT: User power 24V fault: red if the user 24V rail is not enabled or if there has been a fault such as an overcurrent or over temperature event; else off
+- **D4**: U12A FLT: User power 12VA fault: red if the user 12VA rail is not enabled or if there has been a fault such as an overcurrent or over temperature event; else off
+- **D5**: U12B FLT: User power 12VB fault: red if the user 12VB rail is not enabled or if there has been a fault such as an overcurrent or over temperature event; else off
+- **D6**: PWR GD: Main power good indicator: red if any power supply is not enabled or has a fault; else off
+- **D7**: 3.3V: Solid green if 3.3V rail is operational; else off
+- **D9**: UPWR GD: User power good indicator: red if any of the 4 user power rails are not enabled or have a fault (including and overcurrent on any channel); else off
+- **D10**: 5V: Solid green if 5V rail is operational; else off
+- **D12**: APWR GD: Auxiliary power good indicator: red if either of the auxiliary power supplies are not enabled or has a fault (Auxiliary power supplies the USER power as well as other PCBA subsystem power rails at 12V and 24V); else off
+- **D13**: SPWR GD: System power good indicator: red if either of the system power supplies are not enabled or has a fault (System power supplies the power for PCs, any optional GPU, and the primary network switch); else off
+- **D30**: WES BP: Wireless E-Stop Bypass indicator: green if the Wireless E-Stop Bypass is enabled; else off
+- **D31**: WES PFLT: Wireless E-Stop Power fault: red if the power supply is not enabled or has a fault; else off
+- **D46**: XPWR GD: Expansion power good indicator: red if expansion power is not enabled or has a fault; else off
+
+---
+
+## Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../../../accessories/computers/computers.mdx)
+- [Sensors](../../../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../../../accessories/manipulators/manipulators.mdx)
+- [Add-ons](../../../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/husky/a300/integration_husky/kits/_category_.json b/docs/robots/outdoor_robots/husky/a300/integration_husky/kits/_category_.json
new file mode 100644
index 000000000..cc3b026a7
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/integration_husky/kits/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Kits",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/husky/a300/maintenance_husky.mdx b/docs/robots/outdoor_robots/husky/a300/maintenance_husky.mdx
new file mode 100644
index 000000000..874f31a13
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/maintenance_husky.mdx
@@ -0,0 +1,689 @@
+---
+title: Husky A300 Maintenance
+sidebar_label: Maintenance
+sidebar_position: 5
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky_a300.mdx";
+import ComponentReplacingTireOrInnerTube from "/components/maintenance_husky/maintenance_husky_tire_and_inner_tube.mdx";
+import ComponentUpdatingPumaFirmware from "/components/maintenance/firmware_update_puma.mdx";
+import ComponentLeadAcidBatteryCare from "/components/maintenance/lead_acid_battery_care.mdx";
+import ComponentLeadAcidBatteryCareTips from "/components/maintenance/lead_acid_battery_care_tips.mdx";
+import ComponentBillOfMaterialsNote from "/components/maintenance/bill_of_materials_note.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Preventative Maintenance
+
+:::safety-danger
+
+Prior to performing any maintenance, always follow the Lock-Out Tag-Out procedure to
+deactivate Husky.
+
+:::
+
+### Weekly Prevenative Maintenance
+
+Perform the following tasks at least once every week.
+
+#### Circle Check
+
+Perform a circle check around Husky daily to ensure no damage has occurred since its last usage.
+During this visual inspection, ensure the robot is turned on and verify that:
+
+- The Status Lights are functioning correctly by pressing an Emergency Stop button and checking for the
+ Emergency Stop light pattern.
+- The robot was not damaged during the last operation.
+
+:::note
+
+Husky is an all-terrain IP54-rated robot, but it is not waterproof.
+Care should be taken that no part of the main chassis is ever submerged in water.
+When the chassis becomes wet or dirty, wipe it down with a damp cloth and dry with a towel.
+
+If water is suspected to have entered the Husky chassis, power off the robot, open the top plate
+to ensure that any water has drained out through the drain plug, and allow Husky to dry fully
+(for a minimum of 24 hours) prior to putting it back into service.
+
+:::
+
+#### Clean or Replace Air Filter
+
+The air filter is used to prevent dirt and dust from entering the robot at the front air
+intake. It must be cleaned or replaced on a regular basis. High-dust environments will require
+more frequenct maintenance.
+
+:::note
+
+The air filter is foam and can be washed, then reused.
+
+:::
+
+Procedure:
+
+1. Remove the front Livery panel by loosening the quarter-turn latches
+ and lifting the panel up. Be careful not to damage the Emergency Stop
+ Button while removing the panel.
+
+
+
+1. Remove the air filter.
+
+
+
+1. Wash the filter with water and allow it to dry fully.
+ (Alternatively, replace with a new filter.)
+1. Install the clean filter.
+1. Replace the front livery panel by aligning the pins and tighten the quarter-turn latches.
+
+#### Battery Cell Balancing (Quick) {#quick-cell-balance}
+
+Husky is powered by LiFePO4 batteries. The function and health of these
+batteries is monitored by a Battery Management Unit (BMU) which is internal to the battery pack itself.
+
+Over the operating life of Husky, the State of Charge (SoC) of the batteries may start being
+misreported accompanied by a higher voltage difference between the batteries' cells. Typically battery cells
+should be within a range of 50 mV; if not, Husky's batteries may suddenly drop in SoC
+while operating or the Husky may unexpectedly shut off. To resolve this issue, it is required to
+perform regular cell balancing of the battery and BMU.
+
+A "quick" cell balancing should be performed at least once each week.
+
+Procedure:
+
+1. Power off the robot.
+1. Place the robot on a level surface.
+1. Connect the manual charger.
+1. Let the batteries charge for at least four hours.
+
+#### AMP Sensor Cleaning
+
+The AMP variant of Husky is equipped with additional sensors that should be inspected at least weekly
+(more often in high dust/dirt environments) and cleaned as needed.
+
+##### LiDAR Lens Cleaning
+
+1. Inspect LiDAR lens with a flashlight for any dust and/or debris.
+2. Using the Lens Cleaning Wipes (Clearpath p/n 015591), clear the LiDAR of any dust/debris.
+
+:::safety-caution
+
+Do not use abrasive items or solvents on the LiDAR assembly, as this will damage the LiDAR.
+Used and dirty cleaning cloths or wipes will scratch the window over time. The LiDAR window is
+a wear item but proper care and cleaning can significantly extend its life.
+
+:::
+
+##### Camera Cleaning (clean with microfiber cloth or CPR-approved cleaning wipe if dirty)
+
+1. Visually inspect the camera lenses and confirm there is no dust or debris on them.
+1. If necessary, carefully clean the lenses with a microfiber cloth or a Clearpath Robotics-approved
+ cleaning wipe.
+
+:::safety-caution
+
+Do not apply excessive pressure to the camera lenses.
+
+:::
+
+### Monthly Preventative Maintenance
+
+Perform the following tasks once every month.
+
+#### Battery Cell Balancing (Full)
+
+Refer to the notes above regarding the [weekly "quick" cell balancing](#quick-cell-balance).
+In a addition, a full balance of 24+ hours is recommended at least once per month.
+
+Procedure:
+
+1. Power off the robot.
+1. Place the robot on a level surface.
+1. Connect the manual charger.
+1. Let the batteries charge for at least 24 hours.
+
+#### Tire Inspection
+
+Tire pressure may change with temperature and should be checked monthly with a pressure gauge. Inspecting tires,
+releasing pressure, and inflating tires are completed through the tire's inflation stem.
+Tire pressure should not exceed 137 kPa (20 psi), and lower pressure may be desired based on terrain requirements.
+A monthly visual inspection of the tire treads is also recommended. Replacement tires and tubes assemblies can be
+purchased from Clearpath Robotics and can be installed by the user.
+
+:::tip
+
+Husky's wheels can handle a range of different terrains, but work best when inflated to the proper pressure.
+Lower tire pressures, for example 68.5 kPa (10 psi), ensure better traction in rough and varied terrain, where rocks
+or other obstacles may be encountered. This has the adverse effect of lowering drivetrain efficiency and decreasing
+battery charge, so high pressures up to a maximum of 137 kPa (20 psi) should be used when driving on flat surfaces.
+
+Lower tire pressuses also reduce the effective diameter of the wheel, and will impact your odometry readings.
+Odometry is calculated using the average diameter of a tire inflated to 137 kPa (20 psi).
+
+:::
+
+Tire inspection procedure:
+
+1. Power off the robot.
+1. Place the robot on a level surface.
+1. Using a tire pressure gauge, check the pressure on each tire to confirm it is 68.5 - 137 kPa (10 - 20 psi). Add or remove air
+ as needed to ensure each tire is in the proper range. If leaks persist, [change the tire tube](#tire-maintenance).
+1. One wheel at a time, slowly roll Husky through full wheel revolution while inspecting the tire for excessive wear,
+ cuts, or punctures. If any damage is detected, [replace the tire](#tire-maintenance).
+
+#### Drivetrain Inspection
+
+It is recommended that an auditory inspection of the robot drivetrain be performed once per month. Take note of any clicking,
+grinding or irregular skipping sounds while the robot is moving. Note that some clicking in the gearheads is normal during
+stops and starts, due to backlash between the gears.
+
+### 36-Month Preventative Maintenance
+
+Perform the following tasks once every thirty-six months.
+
+#### Battery Health Check
+
+Husky's batteries are expected to last for at least 36 months of
+continuous operation. The actual lifetime experienced will vary greatly depending on the usage and
+operating environment. Contact [Support](#support) for an in-depth assessment of the battery's health if you
+have any concerns.
+
+---
+
+## Hardware Maintenance
+
+### Common Replacement Items {#husky_maintenance_common_replacement_items}
+
+
+
+| Description | CPR Item | Manufacturer | Manufacturer Item | Distributor | Distributor Item |
+| :------------------------- | :------- | :---------------------- | :-------------------- | :---------- | :--------------- |
+| Tire | 000269 | Carlisle | 5100201 | - | - |
+| Tire's inner tube | 000435 | Carlisle | 323790 | - | - |
+| Battery | 025047 | Clearpath Robotics | - | - | - |
+| Battery Charger | 032729 | Clearpath Robotics | - | - | - |
+| Air filter | 032403 | Clearpath Robotics | - | - | - |
+| Main PCBA | 030449 | Clearpath Robotics | - | - | - |
+| BLDC PCBA | 030377 | Clearpath Robotics | - | - | - |
+| Common Core PCBA | 030446 | Clearpath Robotics | - | - | - |
+| 12 V DC/DC PCBA | 030430 | Clearpath Robotics | - | - | - |
+| 24 V DC/DC PCBA | 030433 | Clearpath Robotics | - | - | - |
+| Motor | 031514 | Clearpath Robotics | - | - | - |
+
+See also the common integration parts for [cable ingress](integration_husky#using-the-icotek-cable-entry-system) and
+[breakout connectors](integration_husky#main-circuit-board-connector-summary).
+
+### Replacing Tire or Inner Tube {#tire-maintenance}
+
+Procedure:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the six M8 screws holding the wheel to the motor.
+
+
+
+1. Deflate the tire.
+1. Remove the six M4 screws that hold the split rim together.
+
+
+
+1. Remove the outer wheel rim.
+
+
+
+1. Remove the tire and tube from the inner rim.
+
+
+
+1. Replace the tire and/or tube as needed with new parts. Ensure that the
+ tube is installed in the tire and inflated only far enough that it takes
+ its shape. Inflating further will make reassembly difficult.
+1. Place the tire (with tube) onto to inner rim, aligning the valve stem
+ with the notch in the rim.
+
+
+
+1. Place the outer rim on top, aligning the value stem with the notch in
+ the rim.
+
+
+
+1. Reinstall the six M4 screws, tightening them in a star pattern to 2 Nm.
+
+ :::note
+
+ It may be necessary to use three longer M4 screws on a temporary basis
+ to help pull the inner and outer rims together and ensure alignment,
+ allowing the first three standard M4 screws to be installed. Then,
+ the temporary M4 screws can be removed and the standard ones installed.
+ As you tighten the screws, ensure that the valve stem is not being pinched.
+
+ :::
+
+
+
+
+
+1. Inflate the tire to 20 psi.
+1. Place the wheel on the motor and reinstall the six M8 screws, tightening
+ them in a star pattern to 22 Nm.
+
+
+
+
+### Replacing Circuit Boards
+
+Husky contains several circuit boards (PCBAs). If a failure occurs, there is normally only one
+board that needs to be replaced.
+
+:::safety-caution
+
+Circuit boards are sensitive components and can be damaged easily through electrostatic discharge (ESD).
+Be sure to follow proper ESD protection measures prior to handling any circuit boards.
+
+:::
+
+#### Procedure for replacing the DC/DC and BLDC circuit boards:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the seven screws that fasten the Top Plate to the chassis and remove the Top Plate.
+
+
+
+1. Remove the cable brush holder.
+
+
+
+1. Remove the heat shield covering the DC/DC and/or BLDC circuit boards.
+
+
+
+1. Remove the failing circuit board by gently lifting the board up.
+
+
+
+1. Install the new circuit board by aligning the connector and gently sliding it into place.
+
+
+
+1. Reinstall the heat shields.
+1. Reinstall the cable brush holder.
+1. Put the Top Plate back in place and finger tighten the seven screws that were removed in Step 2.
+ Note that the screw with the sealing washer goes in the inner location and the remaining
+ six screws are installed at the perimeter. Tighten all seven screws to 3 Nm.
+
+
+
+
+#### Procedure for replacing the Common Core circuit board:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the seven screws that fasten the Top Plate to the chassis and remove the Top Plate.
+
+
+
+1. Remove the failing circuit board by removing the two retaining screws, pushing out on the retaining
+ clips, and gently pulling the board out horizontally.
+
+
+
+1. Install the new circuit board by gently sliding it into place horizontally, ensure that the
+ retaining clips are secured, and that the two screws have been installed.
+1. Put the Top Plate back in place and finger tighten the seven screws that were removed in Step 2.
+ Note that the screw with the sealing washer goes in the inner location and the remaining
+ six screws are installed at the perimeter. Tighten all seven screws to 3 Nm.
+
+
+
+
+#### Procedure for replacing the Main circuit board:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the seven screws that fasten the Top Plate to the chassis and remove the Top Plate.
+
+
+
+1. Disconnect all cables from the Main circuit board.
+
+
+
+1. Remove the failing circuit board by removing the retaining screws and then lifting out the board.
+
+
+
+1. Place the old and new Main circuit boards on an ESD mat.
+1. Move the DC/DC, BLDC, and Common Core circuit boards from the old to the new Main circuit board
+ by following the procedures above.
+
+
+
+1. Install the new Main circuit board tighten the retaining screws to 1 Nm.
+1. Reconnect all cables, noting that the labels on the cables should match those on the board.
+1. Put the Top Plate back in place and finger tighten the seven screws that were removed in Step 2.
+ Note that the screw with the sealing washer goes in the inner location and the remaining
+ six screws are installed at the perimeter. Tighten all seven screws to 3 Nm.
+
+
+
+
+### Replacing the Computer
+
+:::safety-caution
+
+Circuit boards are sensitive components and can be damaged easily through electrostatic discharge (ESD).
+Be sure to follow proper ESD protection measures prior to handling any circuit boards.
+
+:::
+
+
+
+:::info
+
+If the existing computer is still operational, a backup of any important data should be
+made prior to its replacement.
+
+:::
+
+Procedure:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the seven screws that fasten the Top Plate to the chassis and remove the Top Plate.
+
+
+
+1. Disconnect all cables from the computer.
+1. Remove the computer by removing the four retaining screws and lifting it
+ out of the robot.
+
+
+
+1. Install the new computer and tighten the four retaining screws to 1 Nm.
+1. Reconnect all cables.
+1. Put the Top Plate back in place and finger tighten the seven screws that were removed in Step 2.
+ Note that the screw with the sealing washer goes in the inner location and the remaining
+ six screws are installed at the perimeter. Tighten all seven screws to 3 Nm.
+
+
+
+1. As needed, reinstall any custom configuration that has been backed up.
+
+### Replacing Motors
+
+Procedure:
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the cable gland bracket on the side of the robot with the motor being
+ replaced by removing five screws.
+
+
+
+1. Disconnect the both sets of motor power and cables from the chassis on the
+ side of the robot with the motor being replaced.
+
+
+
+1. Remove the suspension beam from the chassis by removing the four nuts
+ and washers.
+
+
+
+1. Remove the wheel from the motor ([see above](#tire-maintenance)).
+1. Remove the failing motor from the suspension beam by removing the four
+ M8 screws.
+
+
+
+1. Mount the new motor on the suspension beam and tighten the four screws
+ to 20 Nm.
+1. Re-install the wheel onto the motor ([see above](#tire-maintenance)).
+1. Mount the suspension beam on the chassis, install the four washers,
+ and tighten the four nuts to 30 Nm. (Do not overtighten!)
+1. Reconnect both sets of motor power and cables.
+1. Install the cable gland bracket and tighten the five screws to 1 Nm.
+
+### Replacing Batteries
+
+:::safety-danger
+
+Battery terminals and connected cables / busbars may be live. Follow proper safety procedures when
+performing any maintenance on the batteries.
+
+Only trained personnel authorised by Clearpath Robotics shall perform maintenance on the batteries.
+
+Ensure proper personal protective equipment is used when performing battery maintenance.
+
+:::
+
+1. Follow the [Lock-Out Tag-Out](user_manual_husky#lockout-tagout) procedure.
+1. Remove the cable gland brackets on both sides of the robot by removing five screws on each.
+
+
+
+1. Disconnect all motor power and encoder cables from the chassis.
+
+
+
+1. Remove the seven screws that fasten the Top Plate to the chassis and remove the Top Plate.
+
+
+
+1. Locate the V+ connector and pull the handle to disconnect it.
+
+
+
+1. Disconnect all cables at the front of the electronics tray.
+
+
+
+1. Remove two screws at the front of the electronics tray used to fasten the
+ tray to the side of the robot.
+
+
+
+1. Tilt the electronics tray up to expose the batteries.
+
+
+
+1. Disconnect and remove the positive battery busbar by removing the
+ two fuse covers, disconnecting the terminals, and lifting up the busbar.
+
+
+
+1. Disconnect and remove the negative battery busbar by removing the
+ two screws. This also disconnects the battery ground cable.
+
+
+
+1. Disconnect any CAN bus cables (RJ45 connectors) at the batteries.
+
+
+
+1. Remove the battery to be replaced and the battery to which its
+ terminals were facing. Note that batteries are installed in pairs.
+
+
+
+1. Move the terminal connectors from the old battery to the new battery.
+
+
+
+1. Align the pair of batteries so that their terminals are facing and
+ slide the pair of batteries into the robot. A temporary locking strap
+ to hold the two batteries together may make this step easier.
+1. Reconnect the CAN bus cables (RJ45 connectors).
+1. Re-install the negative battery busbar and ground cable. Tighten
+ the two screws to 5 Nm.
+1. Re-install the positive battery busbar by placing it across the
+ two fuses and tightening the two nuts to 3 Nm.
+1. Replace the two fuse covers.
+1. Tilt the electronics tray back into position and tighten the
+ two screws used to fasten the tray to the side of the robot to 3 Nm.
+1. Reconnect all cables at the front of the electronics tray.
+1. Locate the V+ connector handle and re-install the connector.
+1. Put the Top Plate back in place and finger tighten the seven screws that were removed in Step 2.
+ Note that the screw with the sealing washer goes in the inner location and the remaining
+ six screws are installed at the perimeter. Tighten all seven screws to 3 Nm.
+
+
+
+1. Reconnect all motor power and encoder cables on the chassis.
+1. Re-install the cable gland brackets on both siders of the robot,
+ tightening the five screws on each to 1 Nm.
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+Customer updates of Husky firmware are not supported at this time. Contact [Support](#support) if
+Husky firmware updates are needed.
+
+### Motor Controller Firmware Update {#maintenance_husky_motor_controller_firmware}
+
+Customer updates of Husky firmware are not supported at this time. Contact [Support](#support) if
+Husky firmware updates are needed.
+
+---
+
+## Support {#support}
+
+
\ No newline at end of file
diff --git a/docs/robots/outdoor_robots/husky/a300/troubleshooting_husky.mdx b/docs/robots/outdoor_robots/husky/a300/troubleshooting_husky.mdx
new file mode 100644
index 000000000..fe21006b1
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/troubleshooting_husky.mdx
@@ -0,0 +1,270 @@
+---
+title: Husky A300 Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 6
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky_a300.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+Robots are complex. Issues can occur.
+Examine the following information for possible methods to recover from an unexpected state of Husky.
+See [Components Overview](user_manual_husky#components-overview) for detail on button locations and vehicle state indicators.
+Contact our support team at \ if the issue persists.
+
+---
+
+## Power
+
+### Husky will not turn on
+
+1. Check that both On/Off Breaker is in the "ON" position, then press and hold the Power Button for 1 second.
+2. If the step above does not work, connect the manual charger for one hour to ensure that the batteries
+ have sufficient charge and repeat the step above.
+3. If the issue persists, contact [Support](#support).
+
+## Status lights and status panel
+
+### Status lights are solid red
+
+:::info
+
+This indicates that the MCU is not in contact with the computer. This condition will be seen briefly on startup
+while robot's computer is booting up. If it persists, or is seen after initialization, refer to the
+debugging steps below.
+
+:::
+
+1. Try power cycling the robot to see if the issue persists.
+1. If the issue persists, the base node on the computer has crashed, the network switch has failed, or a serious
+ MCU error has occurred. The following checks can help isolate the source of the error. Run the check below and
+ then contact [Support](#support) for further assistance.
+ 1. From a [wired Ethernet connection](user_manual_husky#ethernet-connection), attempt to ping the robot
+ computer to see if it is accessible:
+ ```
+ ping 192.168.131.1
+ ```
+ 1. From a [wired Ethernet connection](user_manual_husky#ethernet-connection), SSH to the robot
+ computer (`ssh robot@192.168.131.1`) and determine if ROS is running:
+ ```
+ sudo systemctl status clearpath-platform
+ ```
+ 1. From a [wired Ethernet connection](user_manual_husky#ethernet-connection), attempt to ping the robot
+ MCU to see if it is accessible:
+ ```
+ ping 192.168.131.2
+ ```
+
+### Status lights indicated a battery fault
+
+:::warning
+
+Only original chargers from Clearpath Robotics should be used when charging the Husky A300 to
+avoid any damage to the batteries and to reduce hazards. Use proper personal protective
+equipment (PPE) if attempting to handle the batteries.
+
+:::
+
+1. Disconnect any chargers and power cycle the robot to clear any transient state issues.
+2. If the issue persists, power off the robot, charge the robot batteries fully using the
+ manual charger, disconnect the charger, and power on the robot.
+3. If the issues persists, contact [Support](#support).
+
+### Status lights indicate a motor fault
+
+1. Make note of the motor with the fault condition based on the status light pattern.
+1. Power cycle the robot to see if the issue persists.
+1. If the issue persists, [collect a rosbag](#collecting-rosbag) of the following
+ topics, then contact [Support](#support) with the rosbag.
+ - /a300_XXXXX/platform/mcu/status
+ - /a300_XXXXX/platform/mcu/status/power
+ - /a300_XXXXX/platform/motors/debug
+ - /a300_XXXXX/platform/motors/feedback
+ - /a300_XXXXX/platform/motors/status
+ - /a300_XXXXX/platform/motors/system_protection
+ - /a300_XXXXX/platform/safety_stop
+
+### Robot is stuck in emergency stop state
+
+1. Confirm that all [Emergency Stop buttons](user_manual_husky#emergency-stop-buttons) on the robot are disengaged.
+1. Confirm that any remote emergency stop units, if present, have their stop
+ buttons disengaged and restart button pressed (if applicable).
+1. Confirm that all external stop devices are functioning, and that their related switches and
+ relays are closed. You may need to use a multimeter to test voltage between the external stop
+ connector and each of these external stop switches.
+1. Press the [Restart button](user_manual_husky#restart-button).
+1. If the above fails, power cycle the robot to see if the issue persists.
+1. If the issues persists, contact [Support](#support).
+
+:::info
+
+You can confirm the emergency stop state in ROS by running:
+
+```
+ros2 topic echo /a300_XXXXX/platform/emergency_stop
+```
+
+:::
+
+### Status lights indicate that motor protection is engaged {#motor-protection}
+
+1. On the robot, check the following topics to confirm that one or motors are in the protection state:
+ ```
+ ros2 topic echo /a300_XXXX/platform/motors/system_protection
+ ```
+1. Wait 30 minutes for the motors to cool and confirm that the protection state has cleared.
+1. If the issues persists, contact [Support](#support).
+
+### Status panel indicates a communication fault
+
+A communication fault indicates that the Husky's computer to microcontroller Ethernet connection is
+not established. This connection requires:
+
+- The computer to be on.
+- The MCU to be on.
+- The Ethernet cable connection from the computer to the MCU to be functioning properly.
+- The MCU has Husky's firmware installed on it.
+
+If your Husky was functioning recently, the most common causes are:
+
+- Husky's computer is not powered, or is still booting.
+ Wait 60 seconds after startup to see if the computer-to-MCU connection starts after the computer turns on.
+ If not, connect to the computer with SSH, or using a computer monitor to see if the computer is running.
+- The Ethernet cable is not connected. Check that the cable is connected securely at both ends.
+- Someone has changed the robot.yaml configuration file. You can review the robot.yaml on the Husky
+ computer by running:
+ ```
+ nano /etc/clearpath/robot.yaml
+ ```
+
+### Status panel indicates a Wi-Fi fault {#wifi-fault}
+
+1. Confirm that Husky Wi-Fi has been [configured correctly](user_manual_husky#wifi-client-setup),
+ including correct SSID and password. Confirm that the settings are correct in the
+ corresponding `/etc/netplan/` file.
+1. From Husky's computer, run `ip a` to review the status of the wireless interface and
+ determine if the connection has been established.
+1. Power cycle the robot and see if the issue persists.
+1. If the issues persists, contact [Support](#support).
+
+---
+
+## Mobility
+
+### Husky experiences momentary drops in communication, or Husky's velocity has an inconsistent jumping motion
+
+It's possible the robot has reached the thermal limit, or current limit. Refer to the
+[notes above regarding motor protection](#motor-protection).
+
+If you are unsure whether this is the case, [collect a rosbag](#collecting-rosbag) of the following
+topics, then contact [Support](#support) with the rosbag.
+
+- /a300_XXXXX/platform/mcu/status
+- /a300_XXXXX/platform/mcu/status/power
+- /a300_XXXXX/platform/motors/debug
+- /a300_XXXXX/platform/motors/feedback
+- /a300_XXXXX/platform/motors/status
+- /a300_XXXXX/platform/motors/system_protection
+- /a300_XXXXX/platform/safety_stop
+
+### Husky speed is momentarily incorrect when first driving after power up
+
+When first attempting to drive Husky after power-up, Husky's motors go through a calibration process
+(requires less than a quarter of a wheel revolution). During this time, there may be minor deviations in the
+commanded and actual motor speeds. No user intervention is required.
+
+### Husky stutters when first stopped on a slope
+
+To minimize the holding current required when stopped on a slope (to avoid thermal limits over time), Husky
+may undergo a very minor positioning adjustment to reduce forces in the flexible suspension.
+
+To reduce the stutter, only enter a hold position on a slope from a straight direction rather than a turn.
+
+### Husky rolls on a slope during emergency stop
+
+As outlined in the [User Manual](user_manual_husky#husky-emergency-stop-button), during the emergency stop state, no
+power is supplied to the motors. As such, Husky can roll, either due to user intervention or due to
+gravitational forces on a slope.
+
+Husky is equipped with a resistive electric brake that limits its speed in the emergency stop state. The maximum
+roll speed in this state depends on both the slope and payload.
+
+### Husky is making a loud or unusual mechanical noise
+
+- If the sound is coming from the sides of the robot, check the wheels to ensure no debris or object
+ is jammed in or near the wheels.
+- If the sound is coming from the top of the robot, check to make sure the
+ payloads are attached securely.
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+See [above](#wifi-fault).
+
+### Cannot connect to the robot's computer over a network cable
+
+1. Check that the robot is powered on and that no faults are report on the Status Lights or Status Panel.
+1. Check that the external computer is configured correctly (IP address, netmask).
+1. Check that the Ethernet cable is connected securely between the robot and the external computer. Where
+ possible, check for Ethernet link LEDs being illuminated.
+1. Attempt to `ping 192.168.131.1` from the external computer.
+1. If the `ping` fails, connect a keyboard and monitor to the Debug Ports and log in to the
+ computer directly. This confirms the username and password.
+1. Using the keyboard/monitor, run `ip a` and confirm that an interface with IP address of
+ `192.168.131.1` exists.
+1. Power cycle the robot to see if the issue persists.
+1. For additional assistance, refer to the [Networking page](../../../../ros/networking/overview.mdx) or
+ contact [Support](#support).
+
+---
+
+## Computer
+
+### The computer does not start automatically
+
+Refer to the [Mini ITX troubleshooting page](../../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS is not starting
+
+Contact [Support](#support).
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../../accessories/sensors/sensors.mdx).
+
+---
+
+## Support {#support}
+
+
+
+### Collecting a rosbag {#collecting-rosbag}
+
+Our Support team may ask you to create a _rosbag_.
+This is a tool that saves ROS data to a file, so we can review it after the robot has been turned off.
+
+For example, we may ask you to record the _/status_ topic so we can review motor temperatures, and other diagnostic data.
+To create this rosbag, you would:
+
+1. Log into the robot's computer.
+2. Run the command `ros2 bag record /status`
+3. Use your robot as you typically would, trying to recreate the issue you have been experiencing.
+4. Once done, in the terminal, press `ctrl+c` to stop the command.
+5. Enter `ls`, and find the new file that was created. It will have a file extension of _.bag_
+6. Copy this file to your development computer, using a command like [`scp`](https://help.ubuntu.com/community/SSH/TransferFiles).
+ Send this _.bag_ file to Clearpath Robotics in your Support email request.
diff --git a/docs/robots/outdoor_robots/husky/a300/tutorials_husky.mdx b/docs/robots/outdoor_robots/husky/a300/tutorials_husky.mdx
new file mode 100644
index 000000000..58319b867
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/tutorials_husky.mdx
@@ -0,0 +1,31 @@
+---
+title: Husky A300 Tutorials
+sidebar_label: Tutorials
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky_a300.mdx";
+import ComponentTutorialLinks from "../../../../components/_tutorials_link.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Husky Overview
+
+### Introduction
+
+Husky A300 is a rugged and easy-to-use unmanned ground robot for research applications,
+rapid prototyping, and deployments.
+These tutorials will assist you with setting up and operating your Husky.
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/husky).
+
+
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/husky/a300/user_manual_husky.mdx b/docs/robots/outdoor_robots/husky/a300/user_manual_husky.mdx
new file mode 100644
index 000000000..2674cf3ce
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/a300/user_manual_husky.mdx
@@ -0,0 +1,1727 @@
+---
+title: Husky A300 User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionHusky from "/components/introduction_husky_a300.mdx";
+import Support from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+
+
+## Important SAFETY INFORMATION
+
+:::safety-danger
+
+DANGER indicates a hazardous situation which, if not avoided, will result in death or serious injury.
+
+:::
+
+
+
+:::safety-warning
+
+WARNING indicates a hazardous situation which, if not avoided, could result in death or serious injury.
+
+:::
+
+
+
+:::safety-caution
+
+CAUTION indcates a hazardous situation which, if not avoided, could result in minor or moderate injury.
+
+:::
+
+
+
+The top priority of Clearpath Robotics is the safety of its users. Clearpath Robotics produces high power and
+fast-moving pieces of machinery that potentially could cause serious injury, including death, if improperly used
+or maintained. In order to inform our users of some of these risks, throughout Clearpath Robotics documentation
+you will see safety messages corresponding to either a DANGER, WARNING, or CAUTION level as shown
+above.
+
+:::safety-warning[]
+
+**Observe all safety warnings, instructions, illustrations and specifications provided with this automated
+mobile robot.**
+
+Failure to do so may result in fire, equipment damage, property damage and/or personal injury, up to and including death.
+
+:::
+
+The Husky A300 may present risks to users even during normal operation.
+All users should familiarize themselves with the potential hazards of the system so they can anticipate and
+avoid them.
+
+The hazards currently identified are outlined below.
+
+### Fire / Explosion
+
+:::safety-danger[Fire]
+
+**Never use the Husky A300 robot in an environment outside the specified temperature
+and humidity constraints.**
+
+The Husky A300 robot contains lithium iron-phosphate chemistry batteries, which can create
+a fire hazard if used improperly.
+
+:::
+
+
+
+:::safety-danger[Explosion]
+
+**Do not operate Husky A300 in explosive atmospheres, such as in the
+presence of flammable liquids, gases or dust.**
+
+Husky A300 can create sparks which may ignite the dust or fumes.
+
+:::
+
+### Crushing / Impact / Pinching
+
+:::safety-danger[Crushing / Impact]
+
+**Do not operate Husky A300 near people, ladders, vertical drops or stationary racks.
+ Caution and care shall be taken when operating the robot for demonstration purposes
+ to the public that may have vulnerable persons (i.e. children, elderly, etc.).**
+
+The base Husky A300 robot is not equipped with personnel detection or obstacle
+avoidance systems. This may present crush or impact hazards.
+
+:::
+
+
+
+:::safety-warning[Pinch / Crush]
+
+**Keep hands and other objects clear of the Husky A300 at all times.**
+
+Objects can be pinched between the Husky A300 and other fixtures in the environment or
+between the Husky A300 wheels and the Husky A300 frame.
+
+:::
+
+
+
+:::safety-warning[Crushing / Impact]
+
+**Ensure that you follow all guidance for Husky A300 regarding allowable slopes, allowable
+payload mass, and allowable payload location. Refer to [Important System Limits](#important-system-limits)
+for additional information on the robot stability cone.**
+
+Husky A300 can tip over (forward, backward, or sideways) if subjected to slopes or
+vertical drops outside the allowable range, which can lead to crushing or impact hazards.
+
+:::
+
+
+
+:::safety-warning[Crushing / Impact]
+
+**Always use chock blocks on the wheels when powering off the robot.**
+
+When Husky A300 is left unpowered on a slope or ramp, it can roll down the
+slope/ramp, which can lead to crushing or impact hazards.
+
+:::
+
+
+
+:::safety-warning[Crushing / Impact]
+
+**When Husky A300 is being operated on an incline, ensure that there are no objects in
+the environment that will be impacted by a free-rolling robot.**
+
+When Husky A300 is in an Emergency Stop state on a slope or ramp, it can
+roll down the slope/ramp, which can lead to crushing or impact hazards. Consider the
+slope/range angle, payload mass and other [Important System Limits](#important-system-limits).
+
+:::
+
+
+
+:::safety-caution
+
+**Never cross into the path of Husky A300 or place obstacles on its path.**
+
+These obstacles may not be detected in time and could result in an impact.
+
+:::
+
+
+
+:::safety-caution
+
+**Always keep away from Husky A300 in the docking and charging areas.**
+
+Obstacle detection may be reduced in these areas and could result in an impact.
+
+:::
+
+
+
+:::safety-caution
+
+**Always keep away from Husky A300 in narrow aisles and corridors.**
+
+Reduced clearance in these areas and could result in an impact.
+
+:::
+
+
+
+:::safety-caution
+
+**Always keep loose clothing away from Husky A300 along with its
+accessories, attachments, and payloads.**
+
+Using an Emergency Stop button is the only acceptable manner of interacting
+with Husky A300 while it is being operated. This reduces entrapment.
+
+:::
+
+
+
+### Tripping
+
+:::safety-caution
+
+**Ensure that Husky A300 is always parked in a location away from
+walkways when not in use.**
+
+Husky A300 can present a tripping hazard if left in walkways.
+
+:::
+
+
+
+:::safety-caution
+
+**Remain alert if present in the Husky A300 operating area.**
+
+Husky A300 can be anywhere in the operating area at any time and
+may pose a tripping hazard even when not in motion.
+
+:::
+
+### Personal Protective Equipment
+
+:::safety-caution
+
+**Always wear gloves, preferably nitrile gloves, while performing maintenance
+on the robot.**
+
+Internal maintenance on Husky A300 may expose the user to
+chemicals in thermal paste or thread locking adhesives.
+
+:::
+
+
+
+:::safety-caution
+
+**Always wear safety footwear (ie. steel toe) while near Husky A300.**
+
+Husky A300 may move unexpectedly.
+
+:::
+
+
+
+:::safety-caution
+
+**Always wear hearing protection while near Husky A300.**
+
+Husky A300 may emit noise up to 80 dB.
+
+:::
+
+
+### Maintenance
+
+:::safety-warning
+
+**Always follow the proper Lock-Out Tag-Out Procedure for Husky A300 when completing inspections or maintenance.**
+
+Access to live voltage inside Husky A300 may occur if the proper Lock-Out Tag-Out procedure is not followed.
+This may result in electric shock.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Maintain Husky A300.**
+
+Check for misalignment or binding of moving parts, breakage of parts and
+any other condition that may affect Husky A300's operation. If damaged,
+have Husky A300 repaired before use. A poorly maintained Husky A300 may
+result in a risk of shock, fire and/or serious injury.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Never perform maintenance on Husky A300 unless authorized to do so
+by Clearpath Robotics.**
+
+Maintenance procedures not outlined in either this document or the
+maintenance manual can only be performed by a Clearpath Robotics
+Authorized Personnel.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Have your Husky A300 serviced by a qualified repair person using
+only identical replacement parts.**
+
+This will ensure that the safety of Husky A300 is maintained.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Never service damaged battery packs.**
+
+Service of battery packs should only be performed by the manufacturer or authorized service providers.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Never use cleaning agents that could damage plastic parts.**
+
+Certain cleaning agents and solvents damage plastic parts. Some of these are: gasoline,
+carbon tetrachloride, chlorinated cleaning solvents, ammonia and household detergents
+that contain ammonia.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Always ensure Husky A300 is in an Emergency Stop state or shut down completely prior to moving
+it manually.**
+
+Husky A300 may move unexpectedly.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Never push Husky A300 when moving it manually.**
+
+This may cause damage to the motors.
+
+:::
+
+
+
+:::safety-caution[]
+
+**Always power off Husky A300 and set the Battery Breaker to the OFF position prior to performing maintenance.**
+
+Electrical shock may occur when accessing the interior of the Husky A300.
+
+:::
+
+### Operating Conditions and Environment
+
+:::safety-caution[]
+
+**Use Husky A300 in accordance with these instructions, considering the
+working conditions and the work to be performed.**
+
+Use of Husky A300 for operations different from those intended could result in a hazardous situation.
+
+:::
+
+
+
+:::safety-caution
+
+**Perform a site-specific risk assessment.**
+
+Additional items may need to be addressed based on the site-specific operating environment.
+
+:::
+
+
+
+:::safety-caution
+
+**Never attempt to have Husky A300 climb curbs higher than 150 mm, operate near overhanging obstacles,
+or drive across gaps or depressions in the ground more than 200 mm deep, such as the top of stairs,
+at a cliff edge, or at large potholes.**
+
+This may result in damage to the robot drive systems, attachments, or accessories.
+
+:::
+
+
+
+### Payload Maximums
+
+Husky A300 supports a specific maximum payload. Husky A300's maximum payload changes when
+attachments or accessories (including additional batteries) are added because of the weight of the
+attachments and accessories. In the case of a Husky A300 with attachments or accessories,
+the weight of any additional payloads when combined with the weights of any attachments and
+accessories should not exceed the maximum payload documented on the Nameplate.
+
+:::safety-caution
+
+**Never load a Clearpath Robotics product with more weight than is specified by the
+current signage on Husky A300.**
+
+Loading Husky A300 with accessories, attachments, or payloads whose combined weight
+exceeds the maximum payload specified on the Nameplate will prevent Husky A300 from
+correctly determining stopping distances and may also damage the robot, attachment,
+accessory, or payload.
+
+:::
+
+### Disclaimer
+
+The information found within this documentation is subject to change without notice. This document may
+be periodically reviewed and revised in the future. Clearpath Robotics assumes no responsibility for any errors or
+omissions that may appear in this document. In no event shall Clearpath Robotics be liable for any costs or
+damages arising from the use of this document or the hardware and software described within. The
+reference documents listed in this manual shall be applicable at the latest revision in effect.
+
+While Clearpath Robotics does its best to inform its users of potential risks, it is impossible to provide an
+exhaustive list of all possible hazards in your environment.
+
+It is the responsibility of the user to be familiar with all applicable safety standards and ensure that the hardware,
+software, and/or services delivered by Clearpath Robotics (collectively referred to as the "Product") are maintained
+and operated in a safe manner, in a suitable environment, and in accordance with the recommended maintenance requirements
+prescribed by Clearpath Robotics.
+
+Without limiting the foregoing, it is the user's responsibility to ensure that personnel operating the Product are
+adequately trained and comply with all laws, regulations, codes, and safe practices, including health and safety and
+workers' compensation laws, applicable to the user's activities and its ownership, possession, and use of the Product.
+Modification, removal or addition of components, or changes to the functionality or operation of the Product in any way,
+except as expressly authorized by Clearpath Robotics, may jeopardize the safety of the Product. If at any time you have
+any questions or concerns regarding the safe operation of your Clearpath Robotics product, contact [Support](#support).
+
+If at any time you have any questions or concerns regarding the safe operation of your Clearpath Robotics product,
+contact [Support](#support).
+
+---
+
+## Intended Use
+
+Husky A300 is intended for use in:
+
+- indoor and outdoor research laboratories and light industrial environments for inspection, materials transport, and manipulation;
+- environments free of vertical drops greater than 200 mm;
+- environments free of fast-moving people or vehicles;
+- environments free of glass or transparent plastic floors or walls;
+- temperatures between -20°C and +40°C;
+- environments free of open water or other liquids deeper than 130 mm;
+- environments free of grades greater than 15°.
+
+The system is intended to be operated by trained personnel familiar with mobile robotic technology.
+It is intended to be monitored constantly by those personnel during operation.
+
+The system is intended to be operated around trained personnel familiar with the hazards that the system presents.
+
+The system is intended to be operated in the as-furnished condition, without additional equipment, payload or passengers.
+
+---
+
+## Introduction
+
+Husky A300 is a rugged and easy-to-use unmanned ground robot for research applications,
+rapid prototyping, and deployments.
+It is available both as a base platform and as an autonomous mobile platform (AMP).
+
+- Read all instructions before using this product.
+- Familiarize yourself with the [System Specifications](#system-specifications).
+
+
+
+### Risk Reduction
+
+Despite the safety features Clearpath Robotics has put into place, the Husky A300 is heavy and capable
+of moving quickly. The best way to ensure protection of life and equipment around the Husky A300
+is to keep a safe distance from it and pay attention to the status lights and auditory warnings to
+anticipate the robot's intentions. If work is being performed on the charge system, follow local Lock-Out
+Tag-Out procedures for safety.
+
+See [Basic Usage](#basic-usage) for more detail.
+
+### Safety System Functionality
+
+Two methods are used to reduce the system risk:
+
+- The robot is equipped with front and rear Emergency Stop buttons within easy reach of robot.
+- The robot is equipped with an electrical braking system that reduces and limits the speed of
+ the robot when engaging the Emergency Stop.
+
+The safety of each Clearpath Robotics robot needs to be evaluated in the context of the installation where it is used.
+Environmental and process factors in each installation will ultimately govern the risk of injury resulting from
+the interaction of people or equipment in the operating environment with the robot.
+
+### General Warnings
+
+Husky is a rugged and high-performance robot.
+For the safety of yourself and others, always conduct initial experiments and software development with
+the robot raised off the ground. Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any
+other solid flat structure having a height greater than 150 mm under Husky to keep the wheels clear of the
+ground ("up on blocks").
+
+When starting out, favour slower wheel speeds. Husky's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+When Husky is operating, keep clear of the wheels.
+
+### Emergency Stop Buttons {#husky-emergency-stop-button}
+
+:::safety-warning
+
+Ensure the two Emergency Stop buttons are accessible at all times.
+Avoid mounting payloads that extend over the front or rear of Husky and would occlude the Emergency Stop buttons.
+
+:::
+
+The Emergency Stop function allows a person in the physical vicinity of the robot to disconnect drivetrain power.
+Power supply to Husky's motor drivers is enabled by a normally-open relay, which is closed in series with the Emergency Stop switch.
+This Emergency Stop system is intended for use in emergency situations only.
+The Emergency Stop system should not be used as the means of controlling robot motion during regular operation.
+Refer to [Important System Limits](#important-system-limits) for more details on robot behaviour when
+engaging the Emergency Stop system on an incline.
+
+When in Emergency Stop mode, the status lights will illuminate red and Husky will not drive.
+The commands received during Emergency Stop mode are not buffered; Husky will always act on the latest commands received.
+This means that if the commands are stopped before the stop is released, the Husky will not move.
+If the commands are continued, Husky will move at the speed commanded once the stop is released and motion is re-enabled.
+
+This Emergency Stop function can be asserted by pressing either of the red stop actuators present at the front and rear of the Husky, as shown in the following figure.
+The Emergency Stop function can be reset by twisting all depressed actuators until they return to their extended positions, then pressing the Safety Restart button.
+The robot may begin moving again immediately after the Safety Restart button has been pressed.
+
+
+
+### Wireless Emergency Stop (Optional Kit) {#wireless-estop}
+
+In addition to the onboard Emergency Stop buttons, the system may include an optional wireless Emergency Stop kit.
+When the kit is included, it allows a person who is physically separated from the robot to halt its motion and
+prevent re-initiation of motion.
+
+
+
+
+ Wireless Emergency Stop controller
+
+
+
+To assert the stop function:
+
+- depress the red push-button actuator on the side of the provided controller.
+
+To reset the stop function:
+
+- twist the depressed actuator until it returns to its extended position;
+- depress and hold for 1 second the black start button on the side of the controller.
+
+The wireless Emergency Stop is asserted automatically if the robot is not able to communicate wirelessly
+with the controller. This is to ensure that the stop function does not become unexpectedly non-operational as
+a result of robot or operator motion, interference, atmospheric conditions, depleted battery, etc. The
+controller must be powered and within range of the mobile robot to communicate.
+
+The wireless Emergency Stop is intended for use in emergency situations and should
+not be used as the means of controlling robot motion during regular operation.
+
+The wireless Emergency Stop (but not the onboard Emergency Stop buttons) may be disabled by means of
+a key switch described further at [Wireless Emergency Stop Bypass](#wireless-estop-bypass).
+This is to allow the robot to be operated **at higher risk** while,
+for example, the controller battery is dead, out of range, or not accessible.
+
+Operation of the mobile robot while the wireless Emergency Stop is disabled **is not recommended**.
+The system deployer/operator assumes all responsibility for injury to persons or animals, or damage to property,
+arising from the inability to remotely stop the motion of the robot due to the use of this override.
+
+### Electrical System
+
+Husky is powered by two or more 24 V LiFePO4 batteries, similar to the type found in electric wheelchairs, golf carts, and other devices.
+Depending on the system configuration, Husky's batteries are capable of delivering over 3000 W of power.
+This gives Husky's motors their great performance; however, it is also enough power to cause severe bodily harm.
+Please observe the following precautions:
+
+- Charge the battery only with the charger provided by Clearpath Robotics.
+- Please dispose of the batteries properly.
+
+### Lifting and Transport
+
+See [Moving an Unpowered or Disabled Husky](#moving-husky) for details.
+
+### Performance Considerations
+
+Included in Husky are native software checks and limits to protect the robot.
+
+#### Diagnostics Monitoring
+
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+#### Important System Limits {#important-system-limits}
+
+##### Thermal Limits
+
+Husky A300 is equipped with temperature sensors throughout the robot, which are used to monitor
+temperatures and determine fan speeds for proper cooling. In addition, if the robot is approaching
+its critical thermal limits, system throttling may occur. Monitoring these fields over longer periods
+of operation will allow you to ensure that you are not putting excessive wear on Husky's motors and
+other components.
+
+| Sensor | ROS Topic¹ | Message Field | Lower Critical Limit (°C) | Upper Critical Limit (°C) | Notes |
+| :------ | :--------- | :------------ | :------------------------ | :------------------------ | :---- |
+| Motor [1-4] Temperature | /a300_00000/platform/motors/status | drivers[0-3].motor_temperature | -10 | 100 | Does not affect fan speed |
+| Motor Driver [1-4] MCU Temperature | /a300_00000/platform/motors/status | drivers[0-3].mcu_temperature | -20 | 80 | |
+| Motor Driver [1-4] PCB Temperature | /a300_00000/platform/motors/status | drivers[0-3].pcb_temperature | -20 | 80 | |
+| Battery [1-6] Temperature | /a300_00000/bms/battery_state_[1-6] | temperature | -20 | 60 | Charging must occur above 0°C |
+| MCU Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[CC01_MCU] | -20 | 80 | |
+| Fan Controller Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[CC01_FAN[1-4]] | -20 | 80 | |
+| 5V Inductor Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[5V_INDUCTOR] | -20 | 80 | |
+| Main Ground Lug Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[MAIN_GND_LUG] | -20 | 80 | |
+| 24V DC/DC Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[24V_DCDC] | -20 | 80 | |
+| 12V DC/DC Temperature | /a300_00000/platform/mcu/status/temperature | temperatures[12V_DCDC] | -20 | 80 | |
+
+¹ Adjust the `/a300_00000` field with the serial number of your robot.
+
+##### Current Limits
+
+The maximum current draw of the system is limited by the output of the batteries. The maximum
+continuous output for the 2-battery, 4-battery, and 6-battery configurations is 60 A, 120 A, and 150 A, respectively.
+Higher outputs are possible for short periods of time.
+
+Husky A300's motors are rated to draw 17 A continuous, but they will spike to several times higher
+than this, particularly when traversing rough terrain and when turning on the spot.
+To reduce current draw, consider commanding wider-radius turns from your control software.
+
+##### Stability Limits
+
+:::safety-warning
+
+**Always ensure that the centre of mass of the system will not result in tipping hazards in the target environment.**
+
+The end user needs to perform calculations to confirm that the combined centre of
+mass of the system (robot + payload) will not result in tipping hazards in the
+target environment (based on slopes, terrains, etc).
+To ensure safe operation in the target environment, suitable safety margin should be applied
+to the minimum limits outlined below.
+
+When no payload is present, refer to the [System Specifications](#system-specifications) for
+the safe operating limits.
+
+:::
+
+The image below shows the centre of mass for a robot with two batteries.
+
+
+
+
+ Husky A300 Centre of Mass (2-battery configuration), specifications in mm
+
+
+
+The image below provides an example stability cone for Husky A300 (2-battery configuration).
+It shows the location in which the centre of mass of a 100 kg payload must reside to
+avoid tipping while being able to operate at inclines up to 30 degrees, side slopes
+up to 30 degrees, and accelerations/decelerations up to 4 m/s². A safety factor should
+be applied so that the centre of mass is well inside the defined stability cone,
+especially when operating: on uneven surfaces, on large inclines or side slopes,
+in varying friction environments (ice, sand, etc), with low tire pressure and high tire deflection,
+and worn treads.
+
+
+
+
+ Example Husky A300 Stability Cone (2-battery configuration), specifications in mm
+
+
+
+:::note
+
+The images below show the centre of mass and stabililty cone for a 2-battery configuration.
+Appropriate adjustments should be made for 4-battery and 6-battery configurations.
+
+:::
+
+##### Emergency Stop Braking Limits
+
+When Husky A300 has its Emergency Stop engaged, an electrical (resistive) brake is applied to reduce
+the speed of the robot. The payload mass and the incline on which the robot is operating
+will affect the terminal speed of the robot when the Emergency Stop is engaged.
+
+:::safety-warning
+
+**Always confirm terminal speeds in the target environment.**
+
+The performance values outlined below can be affected by various environmental factors such as
+terrain type and should be treated as a reference only. Exact limits should be determined by the
+user in the target operating environment. It is the responsibility of the user
+to ensure that no hazards are present in the the target operating environment.
+
+:::
+
+
+
+| Payload Mass | Incline | Terminal Speed |
+| :----------- | :------- | :------------------|
+| 0 kg | 0° | 0 m/s |
+| 100 kg | 0° | 0 m/s |
+| 0 kg | 15° | 0.5 m/s or less |
+| 100 kg | 15° | 1.25 m/s or less |
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## In Case of a Collision
+
+In case of a collision:
+
+1. Stop the robot by pressing a red Emergency Stop button on the robot or an equipped attachment.
+1. Is anyone hurt? Administer first aid immediately. Seek medical attention if necessary. Follow
+ workplace injury and accident reporting procedures.
+1. Document the incident.
+ 1. Note the time and place.
+ 1. Note which robot was involved.
+ 1. Interview any witnesses.
+ 1. Take photos or make a drawing.
+1. Assess the state of the robot.
+ 1. Visually inspect the robot for damage and take photos of any damage found.
+ 1. If there is no visible damage, observe the robot after it returns to service.
+ 1. If any irregularities or differences in its behavior are observed, remove the affected robot
+ from service and contact [Support](#support). If the damage is extensive, wait for
+ communication from Clearpath Robotics before returning the robot to service.
+
+---
+
+## System Overview
+
+### System Specifications {#system-specifications}
+
+| Specification | Measurement |
+| :----------------------------- | :----------------------------------------------------------------------- |
+| Dimension, Length | 990 mm |
+| Dimension, Width | 698 mm |
+| Dimension, Height | 381 mm |
+| Track Width | 562 mm |
+| Wheelbase Length | 512 mm |
+| Ground Clearance | 139 mm |
+| Mass | 80 kg |
+| Maximum Payload¹ | 100 kg |
+| All-terrain Payload² | 50 kg |
+| Speed, Maximum | 2.0 m/s |
+| Climb Grade³ | 30 ° |
+| Traversal Grade / Sideslope | 30 ° |
+| Operating Temperature⁴ | -20 °C to 40 °C |
+| Storage Temperature | -20 °C to 60 °C |
+| Operating Relative Humidity | 0 to 85% non-condensing |
+| Operating Time, Average⁵ | 4 hours (2-battery) or 8 hours (4-battery) or 12 hours (6-battery) |
+| Operating Time, Standby | 12 hours (2-battery) or 24 hours (4-battery) or 36 hours (6-battery) |
+| Battery | 40 Ah @ 25.6 V (2-battery) or 80 Ah @ 25.6 V (4-battery) or 120 Ah @ 25.6 V (6-battery), LiFePO4 |
+| Standard Battery Charger | 10 A; short-circuit, over-current, over-voltage and reverse voltage protection |
+| Charge Time⁶ | 3-4 hours (2-battery) or 7-8 hours (4-battery) or 8-10 hours (6-battery) |
+| User Power | 12 V @ 10 A, 24 V @ 5 A, VBAT @ 5 A Optional expansion: VBAT @ 40 A |
+| Environmental | IP54 |
+
+_¹ Continuous operation on relatively flat terrain with wide turns._
+_² Robot climbing 30° grade with high-mounted payload, or turning in place in high-friction conditions._
+_³ See also [Important System Limits](#important-system-limits) for additional considerations related to slopes._
+_⁴ Robot must be powered on at a minimum temperature of 0 °C._
+_⁵ Based on 33% driving at 2 m/s with 50 kg payload on level ground and 67% idle._
+_⁶ Based on standard battery charger; fast chargers are available._
+
+
+
+
+ Husky A300 Dimensions
+
+
+
+### System Architecture
+
+Husky is built around a computer running Ubuntu (Intel-based computer or Jetson-based computer), paired with a 32-bit microcontroller unit (MCU).
+The MCU handles low-level hardware functions such as power supply control, light control, screen control, and hardware monitoring.
+The communication channel between the MCU and computer is an Ethernet connection.
+
+---
+
+## Components Overview {#components-overview}
+
+### Exterior Features
+
+The base Husky exterior is shown below and includes:
+
+- 1: Chassis
+- 2: Wheels and motors
+- 3: User payload area, including cable passthrough ports
+- 4: Front and rear bumper bars
+- 5: Status display
+- 6: Status lights
+- 7.1: Power Button
+- 7.2: Emergency Stop Restart Button
+- 8: Protected Access Panel (Battery Breaker, battery charge port, HDMI/USB/Ethernet debug ports, wireless Emergency Stop bypass)
+- 9: Airflow intake (front) and exhaust (rear)
+
+
+
+#### Chassis
+
+The chassis contains the robot's batteries, electronics, and cooling systems. It is an IP54-rated enclosure.
+
+#### Wheels and Motors
+
+Husky is equipped with four wheels, each with its own motor. Power and control cables connect the motors to
+the chassis internals.
+
+#### User Payload Area
+
+Additional payloads such IMUs, lidars, cameras, GPS, manipulators and many more can be integrated with Husky,
+either as part of your Husky purchase or installed after receiving your Husky. You can find a list of supported
+packages and related documentation for payloads in this documention portal, under the following.
+
+- [Computers](../../../accessories/computers/computers.mdx)
+- [Sensors](../../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../../accessories/add-ons/add-ons.mdx)
+
+In addition, refer to [Husky Integration](integration_husky) for details on how to integrate your own payload or
+how to integrate a payload kit from Clearpath Robotics. Each payload kit that ships from Clearpath Robotics
+comes with a custom mounting bracket and cabling for easy attachment to Husky.
+
+#### Front and Rear Bumper Bars
+
+The front and rear bumper bars not only offer protection for Husky, they can be used for a two person lift
+when moving the robot short distances when there is no payload. Refer to [Moving an Unpowered or Disabled Husky](#moving-husky)
+for details on moving Husky longer distances or when there are payloads.
+
+#### Status Display
+
+Husky is equipped with an electronic paper display that provides details on the robot's status.
+
+At present, it shows the robot's remaining battery capacity. Additional status will be added in a future release.
+
+#### Status Lights {#status-lights}
+
+Husky includes four status lights, one on each corner of the chassis. These lights
+indicate the system status according to the table below. In addition, when in the
+"Idle" and "Driving" states, the status lights can be commanded from ROS to display
+indications from autonomy or other higher-level software by publishing to
+the `/a300_00000/platform/cmd_lights` topic (adjusting for your Husky's serial number).
+
+| System State (lowest to highest priority) | Light Output | Description |
+| :---------------------------------------- | :----------- | :---------- |
+| Light Control Fault (or bootup) | Solid red | The MCU is not in contact with the computer. This condition will be seen briefly on startup while robot's computer is booting up. If it persists, or is seen after initialization, either the base node on the computer has crashed, the network switch has failed, or a serious MCU error has occurred. If you suspect one of these conditions, please contact support. |
+| Battery Fault | | An error has been detected with the battery. Please contact support. |
+| Motor Fault | Flashing red at the corner with the motor fault; solid red for the other corners. | An error has been detected with the motor or its controller. Please contact support. |
+| Charged | | The robot's batteries are charged fully. Shore power is available for the robot to operate (excluding drive motors). |
+| Charging (wired or wireless) | | The robot's batteries are being charged, either from the wired/manual charger or the wireless charger. This also provides shore power for the robot to operate (excluding drive motors). |
+| Emergency Stop Engaged | | Emergency Stop mode is engaged. To disengage, twist both red mushroom buttons on the robot to ensure that they are unlatched and press the Safety Restart button. |
+| Needs Safety Restart (after Emergency Stop) | | The Emergency Stop buttons have been disengaged but the Safety Restart button still needs to be pressed to resume driving. |
+| Motor Protection Engaged | Solid magenta | Motor velocity is being limited due to high currents or high temperatures. |
+| Low Battery | | The robot's batteries are in a low charge state. Connect the robot to a charger. |
+| Driving | | The robot is driving (normal operation). |
+| Idle | | The robot is idle (normal operation). |
+
+#### Buttons
+
+##### Emergency Stop Buttons {#emergency-stop-buttons}
+
+The Husky is equipped with two Emergency Stop buttons, one at the front and one at the rear. Pressing either of
+these buttons removes power from the drivetrain. To clear the stop condition, all Emergency Stop buttons must
+be disengaged and the Safety Restart Button must be pressed. Refer to [Emergency Stops](#husky-emergency-stop-button) for more details.
+
+##### Safety Restart Button {#restart-button}
+
+To clear the stop condition, all Emergency Stop buttons must be disengaged and the Safety Restart Button must be pressed.
+Refer to [Emergency Stops](#husky-emergency-stop-button) for more details.
+
+Pressing the Safety Restart Button will have no effect when not in the stop condition or when one or more Emergency Stop
+buttons are engaged.
+
+##### Power Button
+
+The Power button is used to power the robot on and off. From the "OFF" state, pressing
+the button will cause the robot to power on. From the "ON" state, pressing the button will cause the robot to power off.
+Note that the Power button has no effect when the Battery Breaker is in the "OFF" position, unless
+a charger is connected to the robot.
+
+#### Protected Access Panel
+
+The rear of the robot has an access panel, protected by a Lock-Out, that contains the Battery Charge Port, Battery Breaker,
+Debug Ports, and Wireless Emergency Stop Bypass. Opening the access panel cover puts the robot into a stop condition to
+prevent the robot from driving while cables may be connected. To clear the stop condition, close the access panel cover
+and press the Safety Restart Button.
+
+
+
+##### Lock-Out
+
+When equipped with a lock, the Lock-Out prevents access to the Battery Breaker, Battery Charge Port, and Debug Ports.
+See [Lock-Out Tag-Out](#lockout-tagout) for additional details.
+
+##### Battery Breaker
+
+
+
+
+ Husky A300 Battery Breaker, Off Position
+
+
+
+When the breaker is in the "OFF" position, the Battery Breaker disconnects the internal batteries from the rest of
+the robot's systems. In this position:
+
+- the Power Button can be used to turn the robot on/off only if a charger is connected;
+- the robot will be off (unpowered) if no charger is connected and any Power Button presses will have no effect.
+
+When the breaker is in the "ON" position:
+
+- the Power Button can be used to turn the robot on/off;
+- the robot can be charged (manual and wireless charger options), regardless of whether the
+ robot is powered on or off.
+
+:::note
+
+Husky ships with the breaker in the "OFF" position to prevent battery drain during shipping.
+
+:::
+
+##### Battery Charge Port
+
+The charger included in your Husky shipment can be used to charge the robot's internal batteries by connecting it
+to the Battery Charge Port. Refer to [Charging](#charging) for additional information on charging the robot's batteries.
+
+:::note
+
+The charger also functions as "shore power" and may provide power to the robot indefinitely while connected,
+up to the maximum output current of the charger. If total system power draw is above the output current of the charger,
+which may occur with certain custom payloads, the batteries will continue to discharge even when a charger
+is connected.
+
+:::
+
+##### Debug Ports
+
+The robot is equipped with a Gigabit Ethernet port, a USB 3.0 (Type A) port, and an HDMI port. These can be used for debugging
+without needing internal access to the robot. These ports are all connected directly to the robot's computer.
+
+##### Wireless Emergency Stop Bypass {#wireless-estop-bypass}
+
+In addition to the Emergency Stop buttons on the robot, if your Husky A300 is equipped with an optional wireless Emergency Stop kit,
+it is possible to disable this function with the override key switch. Refer to [Wireless Emergency Stop](#wireless-estop),
+[Integration](integration_husky#wireless-stop), and the image below for further details.
+
+
+
+#### Airflow Intake and Exhaust
+
+The robot is equipped with a cooling system with air intake at the front of the robot and exhaust at the rear
+of the robot. The amount of airflow scales automatically depending on the temperatures reported by various sensors.
+
+### Interior Features
+
+Removing the top plate exposes the electronics tray, which contains the following:
+
+1. Computer
+2. GPU (optional)
+3. IMU
+4. User power expansion
+5. Network switch
+
+
+
+
+ Husky A300 Electronics Tray
+
+
+
+Removing the electronics tray exposes the batteries. Husky is available in 2-battery, 4-battery,
+and 6-battery configurations.
+
+
+
+#### Computer
+
+Husky is equipped with an Intel-based computer in a Mini-ITX form factor. Several SKUs are possible
+depending on the desired performance of the system.
+
+#### GPU (Optional)
+
+An optional GPU can be added and connected to the computer for additional graphics processing.
+
+#### IMU
+
+A standard 6-axis IMU is included by default. Upgrade options are available.
+
+#### Power Expansion
+
+Husky A300 provides power breakouts to allow the integration of customer payloads.
+Refer to [User Power Connections](integration_husky#user-power-connections) and
+[High Power Expansion Kit](integration_husky#high-power-expansion-kit) for more details.
+
+#### Network Switch
+
+Husky includes a network switch, which allows additional payloads to be integrated with an Ethernet
+connection. See also [Husky Networking](#husky-networking).
+
+#### Batteries
+
+Husky can be equipped with two, four, or six batteries. These batteries are not hot-swappable.
+Refer to [Maintenance](maintenance_husky) for details on battery maintenance.
+
+### Autonomous Mobile Platform (AMP) Kit
+
+Husky A300 can be equipped with an Autonomous Mobile Platform (AMP) Kit, which includes extra sensors
+(as illustrated below) and [OutdoorNav](/docs_outdoornav_user_manual) software. Combined, this allows
+for autonomous navigation of Husky A300 and related system development.
+
+:::safety-danger[Crushing / Impact]
+
+**Never rely on the AMP kit as only method to avoid collisions.**
+
+While extensive testing has been performed to validate system robustness, autonomous operation of
+Husky A300 with the AMP kit is not safety rated in accordance with ISO 13849 or similar standards.
+The AMP kit is intended for research and development purposes and is not intended for use in deployments
+where hazards are mitigated exclusively through the use of the AMP kit. The user is responsible for
+ensuring that the Husky A300 with AMP kit does not result in hazards in the target operating
+environment.
+
+Contact [Support](#support) for details on how to upgrade to a safety-rated autonomy system for
+Husky A300.
+
+:::
+
+
+
+
+ Husky A300 AMP
+
+
+
+### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855, and is shown in the figure below.
+Husky's front is shown.
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+
+
+### Robot Equations
+
+As a starting point, Clearpath Robotics recommends using the following relationship between wheel velocity and platform velocity:
+
+$$
+v=\cfrac{v_{r}+v_{l}}{2}
+$$
+
+$$
+\omega=\cfrac{v_{r}-v_{l}}{W}
+$$
+
+$v$ represents the instantaneous translational speed of the platform and $\omega$ the instantaneous rotational speed.
+$v_{r}$ and $v_{l}$ are the right and left wheel velocities, respectively.
+$W$ is the effective track of the robot, 0.562 m.
+
+---
+
+## Unboxing
+
+### Time Required
+
+Approximately 15 minutes.
+
+### Required tools
+
+- 14 mm socket and driver
+
+### What's Inside
+
+Your Husky A300 base platform shipment contains the following:
+
+- Husky A300 robot
+ - Two or more LiFePO4 batteries (integrated)
+ - Computer (integrated)
+ - IMU (integrated)
+ - Network switch (integrated)
+- One battery charger
+- One PS4 controller
+
+If you purchased the AMP variant, standard payload modules or custom integration services with Husky, then additional equipment
+will be included per your specific configuration, plus further documentation as required.
+
+### Unboxing the Husky A300
+
+Follow the steps below to remove Husky A300 from its crate.
+
+1. Remove the bolts securing the front panel of the crate.
+
+
+
+1. Position the front panel as a ramp at the bottom of the crate.
+
+
+
+1. Loosen and remove the retaining straps.
+1. Gently roll the Husky A300 out of the crate.
+
+---
+
+## Quick Start {#quick-start}
+
+This section outlines how to power up and drive the robot. For more details on these steps,
+refer to [Basic Usage](#basic-usage).
+
+1. Open the Access Panel cover, set the Battery Breaker to the "ON" position, and close the Access Panel cover.
+1. Press and hold the Power Button for one second and then release it.
+1. Wait one minute for the robot to initialize fully.
+ Once initialized, the front lights should be solid white and the rear lights should be solid red.
+1. Press and release the Safety Restart button.
+1. Press the "PS" button on the joystick controller to connect it to the robot.
+1. Press either the L1 or R1 enable button (slow or fast mode, respectively) and use the left
+ thumbstick to drive Husky. See further details at [Connecting and Using the Controller](#controller).
+
+---
+
+## Basic Usage {#basic-usage}
+
+This section describes the operation of the Husky.
+
+### Lock-Out Tag-Out {#lockout-tagout}
+
+Only trained personnel authorised by Clearpath Robotics shall open the Husky A300.
+
+:::safety-danger
+
+**Always perform the Lock-Out Tag-Out procedure prior to performing maintenance inside Husky A300.**
+
+The Battery Breaker terminal connected to the battery (displayed below) is live even when the
+robot is locked out. These terminals at the breaker and at the battery are protected with rubber covers.
+Do not remove these or any other terminal covers. The main chassis will act as the negative side
+of the battery. If the robot is correctly locked out, all live terminals are protected. The robot
+must be locked out to properly protect the remaining connections.
+
+:::
+
+Normal preventative maintenance tasks will not require the user to open the Husky A300 to expose
+these connections.
+
+
+
+
+ Husky A300 Live Connections
+
+
+
+:::safety-caution
+
+**Always wear safety boots or shoes with steel toes while working with a Husky A300.**
+
+The robot may move unexpectedly.
+
+:::
+
+#### Husky A300 Lock-Out Tag-Out
+
+1. Press one of the Emergency Stop buttons.
+1. Press and hold the Power Button for one second, then release it.
+1. Wait until all lights on Husky have turned off (up to 10 seconds). This indicates that all electronics have
+ powered off.
+1. Open the Access Panel cover, set the Battery Breaker to the "OFF" position, and close the Access Panel cover.
+1. Clamp the Lock-Out Tag-Out lock to prevent the Access Panel cover from being opened.
+
+
+
+
+ Husky A300 Lock-Out
+
+
+
+### Starting Up
+
+Before turning on Husky the first time, place Husky "up on blocks", making sure that the wheels are clear
+of the ground. This reduces hazards while becoming familiar with how the various subsystems work.
+
+To power on Husky:
+
+1. Open the Access Panel cover, set the Battery Breaker to the "ON" position, and close the Access Panel cover.
+1. Press and hold the Power Button for one second and then release it.
+1. Wait one minute for the robot to initialize fully. During startup, the Status Lights will be solid red.
+ Once initialized, the front lights should be solid white and the rear lights should be solid red.
+1. Press and release the Safety Restart button to be able to drive the robot.
+
+### Shutting Down {#shutting-down}
+
+If you are servicing, transporting, or storing Husky, perform the [Lock-Out Tag-Out](#lockout-tagout) procedure; otherwise,
+perform the steps below.
+
+To power off Husky:
+
+1. Press and hold the Power Button for one second and then release it.
+1. Wait until all lights on Husky have turned off (up to 10 seconds). This indicates that all electronics have
+ powered off.
+
+### Charging {#charging}
+
+:::safety-danger
+
+**Always use original chargers from Clearpath Robotics when charging the Husky A300.**
+
+Using other chargers may cause damage to the batteries.
+
+:::
+
+
+
+:::safety-warning
+
+**Never charge Clearpath Robotics robots in environments with combustable materials.**
+
+Sparks may occur and could cause combustable materials to ignite.
+
+:::
+
+Husky A300 ships with its batteries installed and they charged in place. The batteries
+may be charged with the standard manual/wired charger or with the optional wireless charger upgrade kit.
+
+#### Manual/Wired Charging
+
+A manual (wired) charger can be used to charge the Husky batteries by following the steps outlined below.
+Two manual chargers are supported with Husky A300:
+
+- Husky A300 Standard Manual Charger (Henryuan Model PSY27710000): 277 W, indoor use only
+- Husky A300 High Power Manual Chargers
+ - Robots with 2 batteries: Delta-Q Model IC650: 650W, indoor or outdoor use (IP66)
+ - Robots with 4 or 6 batteries: Delta-Q Model IC1200: 1200 W, indoor or outdoor use (IP66)
+
+:::safety-caution
+
+**Never use the Husky A300 Standard Manual Charger in outdoor environments.**
+
+This charger is for indoor use only. Only use this charger when the
+robot is inside and after it has been dried. Otherwise, electric shock
+may occur.
+
+:::
+
+
+
+:::note
+
+The batteries can be charged when the robot is powered on or powered off, though the charging will progress more quickly when the
+robot is powered off.
+
+:::
+
+1. Open the Access Panel cover to expose the Battery Charger Port.
+1. Connect the DC output cable from the Standard Charger to the battery terminal connector (red-to-red, black-to-black).
+1. Plug the Standard Charger power cord into the Standard Charger and then into a wall receptacle.
+ The LED on the Standard Charger will illuminate red and Husky's [Status Lights](#status-lights) will pulse yellow/green
+ (if the robot is powered on).
+1. When battery is charged fully, the LED on the Standard Charger will illuminate green if the the robot is powered off.
+ Alternatively, if the robot is powered on the LED on the Standard Charger will remain red and Husky's [Status Lights](#status-lights)
+ will pulse blue/green.
+1. Unplug the Standard Charger from the wall and then disconnect it from the Battery Charger Port.
+1. Close the Access Panel cover.
+
+#### Wireless Charging (Optional Kit)
+
+The system may include an optional wireless charging kit.
+When the kit is included, it includes two main parts:
+
+- a wireless charging receiver mounted on the right side of the Husky A300;
+- a docking station, separate from the robot, which includes the wireless charging transmitter.
+
+This optional kit allows the Husky A300 to be charged by positioning it such that the
+wireless charging receiver is located near the wireless charging transmitter. For maximum
+charge rates, the receiver should be positioned within 30 mm of the transmitter. This
+positioning can be performed manually by the user or automatically using the
+[OutdoorNav docking function](/docs_outdoornav_user_manual/web_user_interface/ui_overview),
+when the robot is equipped with the optional AMP Kit. Note that wireless
+charging can be performed with the robot in both the powered and unpowered states, as
+long as the Battery Breaker is in the "ON" position.
+
+When the wireless charging receiver is near the transmitter, charging will begin automatically without
+any user intervention.
+When charging is complete, the transmitter will stop charging automatically and the status display
+will be updated accordingly. Note that when the robot is powered
+on, the charging may remain on indefinitely (though at a reduced rated) as the transmitter
+provides the on-going power for the powered-on electronics.
+
+At any time while charging, the robot can be moved away from the transmitter to
+stop charging and begin using the robot. No other user intervention is required to
+stop charging.
+
+
+
+### Moving an Unpowered or Disabled Husky {#moving-husky}
+
+It is much easier to manually push an unpowered robot than one that is powered, as a powered robot will
+attempt to hold its position, possibly resulting in damage to the robot. Pushing an unpowered
+robot at normal speeds will not damage it.
+
+To shut down Husky and move it manually:
+
+1. Follow the steps in [Shutting Down](#shutting-down), including the [Lock-Out Tag-Out](#lockout-tagout) procedure.
+1. Carefully remove or fully secure any payloads on Husky.
+1. Carefully push or transport Husky to the desired location.
+1. After moving Husky, make sure to position it on level ground to prevent it from rolling.
+
+:::safety-caution
+
+**Never push Husky A300 using a powered device at speed above 2 m/s, such as
+pushing it with a forklift.**
+
+This can damage the internal circuitry. If a Husky needs to be moved manually over longer
+distances, it should be lifted and secured to a travelling vehicle or palette for transport.
+
+:::
+
+#### Husky Lift Points
+
+Husky has a robust structure that allows it to be picked up or reoriented by hand, using the bumper bars, or with
+the use of lifting machinery such as a crane, using lifting straps on the bottom of the robot. When using
+lifting straps, they should be positioned as shown in the images below. The lifting equipment and straps used
+shall be rated to minimum weight equal to the weight of Husky, including any mounted payloads.
+See [System Specifications](#system-specifications) for the weight of Husky and its maximum payload.
+
+
+
+:::safety-warning
+
+**Never attempt a 1-person lift of Husky A300.**
+
+Husky A300 exceeds the weight to be lifted by a single individual. If lifting by
+hand, ensure to ask for assistance and use proper lifting techniques.
+
+:::
+
+
+
+:::safety-warning
+
+**Never use the bumper bars to lift Husky A300 with mounted payloads.**
+
+This may exceed the lift rating for the bumper bars. It may also exceed the
+safe limit for a 2-person lift. Use lifting straps instead.
+
+:::
+
+
+
+:::safety-caution
+
+**Ensure that the the lifting straps are not applying a force
+on any structures not suitable for lifting, especially mounted payloads.**
+
+This may cause damage to the equipment and shifting of the payload during lifting.
+
+:::
+
+### Storage
+
+Before storing Husky for an extended period of time (greater than two days), Husky A300 must be
+charged to at least 50%. Also, the Battery Breaker must be set to the "OFF" position before storing
+Husky A300 for an extended period of time.
+
+Even with the batteries disconnected from the system, the batteries will discharge over time and must
+be charged periodically. It is recommended that a Husky A300 in storage be powered on at least
+once every three months, its battery levels checked, and if the reported charge level is below 20% it
+should be charged back up to at least 50% before returning it to extended storage.
+
+Husky and any spare batteries outside of the vehicle should be stored within the
+temperature range outlined in [System Specifications](#system-specifications).
+
+### Husky Networking {#husky-networking}
+
+Husky provides both Ethernet and Wi-Fi network connection options. The details below outline
+the configuration for the different options.
+
+#### Connecting to Husky over an Ethernet Connection {#ethernet-connection}
+
+Regardless of the Wi-Fi mode, Husky can always be accessed over an Ethernet connection. Follow
+the steps below to connect to Husky over an Ethernet connection.
+
+1. Open the Access Panel cover on Husky to expose the debug Ethernet port.
+1. Connect an Ethernet cable from Husky's debug Ethernet port to a computer.
+1. Set the computer's IP address and netmask as shown below.
+ - **IP Address**: 192.168.131.100
+ - **Netmask**: 255.255.255.0
+1. Confirm that you can ping Husky from the computer's terminal window in Linux or the
+ command prompt in Windows by entering the following command:
+ ```ping 192.168.131.1```
+ The output should be similar to the following.
+ ```
+ Pinging 192.168.131.1 with 32 bytes of data:
+ Reply from 192.168.131.1: bytes=32 time<1ms TTL=128
+ Reply from 192.168.131.1: bytes=32 time<1ms TTL=128
+ Reply from 192.168.131.1: bytes=32 time<1ms TTL=128
+ Reply from 192.168.131.1: bytes=32 time<1ms TTL=128
+
+ Ping statistics for 192.168.131.1:
+ Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
+ Approximate round trip times in milli-seconds:
+ Minimum = 0ms, Maximum = 0ms, Average = 0ms
+ ```
+1. Connect to your robot via SSH. To do so, execute the following in a terminal window:
+ ```
+ ssh robot@192.168.131.1
+ ```
+ You will be promoted to enter a password. The default password is `clearpath`.
+ :::note
+ All Clearpath robots ship from the factory with their login password set to `clearpath`.
+ Upon receipt of your robot we recommend changing the password. To change the password,
+ run the following command on the robot:
+ ```
+ passwd
+ ```
+ This will prompt you to enter the current password, followed by the new password twice.
+ While typing the passwords in the `passwd` prompt there will be no visual feedback
+ (e.g. "*" characters).
+ :::
+
+#### Husky Wi-Fi Network Configuration
+
+Husky can be configured to connect to an existing Wi-Fi network.
+
+##### Connecting Husky to a Network over Wi-Fi {#wifi-client-setup}
+
+To get Husky connected to your local Wi-Fi network, follow the setup below.
+
+1. Follow the steps for [Connecting to Husky over an Ethernet Connection](#ethernet-connection).
+1. Run `sudo clearpath-computer-setup` and follow the [Custom Networking](../../../../ros/networking/computer_setup#custom-networking)
+ instructions for setting up the Wi-Fi connection.
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Husky and powered on.
+Follow the instructions in the [Joystick Controller Pairing](../../../../ros/installation/controller)
+to pair the controller to Husky.
+
+To teleoperate Husky, first [clear any stop conditions](#husky-emergency-stop-button). Then, referring
+to the following images, press an enable button (either slow or fast mode) and use the left
+thumbstick to drive Husky.
+
+In slow mode, the maximum robot speed is 0.3 m/s; in fast mode, the maximum robot speed is 2.0 m/s.
+
+
+
+
+ PS4 Contoller
+
+
+
+### Using ROS
+
+Robot Operating System (ROS) is an extensible framework for controlling and working with robotic systems.
+Clearpath Robotics recommends using ROS with your robot. If this is your first time using ROS, it is strongly
+recommended to run through our series of [ROS tutorials](../../../../ros) to learn
+the basics of ROS.
+
+Husky A300 is compatible with ROS 2 Jazzy.
+
+---
+
+## Maintenance
+
+See [Husky A300 Maintenance](maintenance_husky) for details on Husky maintenance.
+
+---
+
+## Disposal
+
+Always observe environmental protection regulations valid to your region.
+
+If disassembling the Husky A300 for disposal, pass on any commercially-viable disassembled
+components for recycling. Separate materials as far as possible by type.
+
+Do not incinerate or dispose of the batteries. Return end-of-life or defective batteries to your nearest
+recycling center per appropriate local regulations.
+
+---
+
+## Troubleshooting
+
+See [Husky A300 Troubleshooting](troubleshooting_husky) for details on Husky troubleshooting.
+
+---
+
+## Declarations
+
+### FCC Supplier's Declaration of Conformity
+
+**47 CFR § 2.1077 Compliance Information**
+
+**Husky A300**
+
+**Responsible Party**
+
+Rockwell Automation, Inc.
+1201 South Second Street
+Milwaukee, Wisconsin
+53204-2410
+
+**Point of Contact**
+
+Ryan Gariepy, CTO (OTTO Motors and Clearpath Robotics)
+ryan.gariepy@rockwellautomation.com
+1-844-733-6886
+
+This device complies with Part 15 of the FCC Rules.
+
+Operation is subject to the following two conditions: (1) this device may
+not cause harmful interference, and (2) this device must accept any
+interference received, including interference that may cause undesired operation.
+
+Contains Transmitter Module FCC ID: PD9AX210NG
+
+Changes or modifications not expressly approved by Clearpath Robotics Inc. could void
+the user's authority to operate the equipment.
+
+This equipment has been tested and found to comply with the limits for a Class A
+digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide
+reasonable protection against harmful interference when the equipment is operated in a
+commercial environment. This product generates, uses, and can radiate radio frequency
+energy and, if not installed and used in accordance with the manufacturer's instruction
+manual, may cause harmful interference with radio communications. Operation of this
+product in a residential area is likely to cause harmful interference, in which case you will
+be required to correct the interference at your own expense.
+
+These limits are designed to provide reasonable protection against harmful interference in
+a non-residential installation. However, there is no guarantee that interference will not
+occur in a particular installation.
+If this equipment does cause harmful interference to radio or television reception, which can
+be determined by turning the equipment off and on, the user is encouraged to try to correct
+the interference by one or more of the following measures:
+ - Reorient or relocate the receiving antenna.
+ - Increase the separation between the equipment and receiver.
+ - Connect the equipment into an outlet on a circuit different from that which the receiver is connected.
+ - Consult the dealer or an experienced radio/TV technician for help.
+
+FCC Radiation Exposure Statement: This product complies with FCC §2.1091(b) for mobile RF exposure limits,
+set forth for an uncontrolled environment and is safe for the intended operation as described in this manual.
+Per FCC requirements, maintain a distance of more than 8 inches (20 cm) between any person and the host device.
+
+### Innovation, Science and Economic Development Canada (ISED) Compliance Notice
+
+Contains Transmitter Module IC: 1000M-AX210NG
+
+This device contains a license-exempt transmitter/receiver that complies with Innovation,
+Science and Economic Development (ISED) Canada's license-exempt RSS(s). Operation is
+subject to the following 2 conditions: (1) this device may not cause interference, and
+(2) this device must accept any interference, including interference that may cause
+undesired operation of the device.
+
+CAN ICES-003(A) / NMB-003(A)
+CAN ICES-002(A) / NMB-002(A)
+
+This Class A digital apparatus complies with Canadian ICES-002 and ICES-003.
+
+Under Industry Canada regulations, this radio transmitter many only operate using an
+antenna of a type and maximum (or lesser) gain approved for the transmitter by Industry
+Canada. To reduce potential radio interference to other users, the antenna type and its
+gain should be so chosen that the equivalent isotropically radiated power (e.i.r.p.) is
+not more than the necessary for successful communication.
+
+ISED Radiation Exposure Statement: This product complies with the Canadian Standard
+RSS-102 for portable RF exposure limits, set forth for an uncontrolled environment
+and is safe for the intended operation as described in this manual. Per ISED requirements,
+maintain a distance of more than 8 inches (20 cm) between any person and the host device.
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/husky/husky.mdx b/docs/robots/outdoor_robots/husky/husky.mdx
new file mode 100644
index 000000000..1c68bbb5d
--- /dev/null
+++ b/docs/robots/outdoor_robots/husky/husky.mdx
@@ -0,0 +1,40 @@
+---
+title: Husky Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+There are two main models of Husky: [Husky A200](a200/user_manual_husky) and
+[Husky 300](a300/user_manual_husky). Locate the model number
+sticker on your Husky to determine which model you have and select the appropriate
+documentation.
+
+
diff --git a/docs/robots/outdoor_robots/jackal/_category_.json b/docs/robots/outdoor_robots/jackal/_category_.json
new file mode 100644
index 000000000..85befb884
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Jackal",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/jackal/integration_jackal.mdx b/docs/robots/outdoor_robots/jackal/integration_jackal.mdx
new file mode 100644
index 000000000..7211fffe2
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/integration_jackal.mdx
@@ -0,0 +1,123 @@
+---
+title: Jackal Integration
+sidebar_label: Integration
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionJackal from "/components/introduction_jackal.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import Support from "/components/support.mdx";
+
+
+
+To attach custom hardware to Jackal, you will have to take care of mechanical mounting, electrical
+supply, and software integration. This guide aims to equip you with respect to these challenges.
+
+---
+
+### Mechanical Mounting
+
+When determining mechanical mounting, you can use the Standard square mounting pattern on the lid of the Jackal.
+At this time, the "PACS™" mounting system is not available for Jackal.
+
+#### Mechanical, Standard
+
+A standard Jackal is delivered with an 80 mm square mounting pattern of M5 threaded holes on its lid, which can be
+used for attaching external payloads. The mounting holes come with M5 screws pre-installed.
+You may mount your hardware directly onto the lid or you may design and mount a new plate to the lid and secure
+it to the lid using M5 screws.
+
+### Mechanical, PACS
+
+While Jackal does not yet support PACS directly, the following kits may simplify your integration.
+
+- [OutdoorNav Starter Kit](../../accessories/add-ons/outdoornav_starter_kit.mdx)
+
+### Electrical Integration {#jackal-payload-electrical-integration}
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+
+#### Data Connections
+
+Data connections may be brought through the hatch and connected directly to the internal computer. Both
+of Jackal's internal computer options support USB3 and Ethernet connectivity. With the performance
+computer, the PCIe slot may be used to supply Firewire, Thunderbolt, or additional USB3 ports, as necessary.
+
+Additionally, the internal mounting area may be used for an Ethernet switch, when attaching multiple
+Ethernet payloads, or for a PoE power injector as required.
+
+#### Connector Summary
+
+The Jackal User Power Board (UPB) board provides a number of connections for power.
+These are summarized in the following table and described in more detail in the following sections.
+
+- For the High Current VBAT User Power, terminate your payload's power lead with the appropriate terminals.
+- For the User Power Ports, terminate your payload's power lead with the appropriate crimps and pins.
+ for the four pin Molex connector. This option may be best if you are removing your payload from Jackal frequently.
+- For the User Power Screw Terminals, pull out the black terminal block, and use a small screwdriver to securely attach power leads to it.
+ Confirm voltage and polarity before reconnecting the terminal block.
+
+| Port (see Figure) | MCU board connector | Mating connector | Crimp terminals | Crimping tool |
+| :--------------------------- | :-------------------------------------------------------------------------------------------------- | :------------------------------------------------- | :----------------------------------------------------------- | :--------------- |
+| High Current VBAT User Power | Anderson PP15/45 1327-BK (red) + 1327G6-BK (black) + Anderson PCB45 1336G1 (lower) + 1337G1 (upper) | Anderson PP15/45 1327-BK (red) + 1327G6-BK (black) | Anderson 262G2-LPBK (AWG 16-20) or 261G3-LPBK (AWG 10-14) | Anderson 1309G8 |
+| User Power Ports | Molex 0039301040 | Molex 0039012040 | Molex 0507528200 (AWG 20-22) or Molex 0503518100 (AWG 22-28) | Molex 2002184900 |
+| User Power Screw Terminals | Molex 39522-1006 | Molex 39520-0706 | N/A | N/A |
+
+
+
+
+ User power board
+
+
+
+#### User Power Connections
+
+Similar to the data connections, power leads may be brought through the hatch, and connected to the User Power Board.
+The following are available as user power:
+
+- Unregulated VBAT power (25.6 V nominal, 16 A max), shared across the High Current VBAT User Power (16 A max),
+ User Power Ports (8 A max per port) and the User Power Screw Terminals (15 A max)
+- Regulated 12 V power (7 A max), shared across the User Power ports (7 A max per port) and the User Power
+ Screw Terminals (7 A max)
+- Regulated 5 V power (5 A max), shared across the User Power ports (5 A max per port) and the User Power
+ Screw Terminals (5 A max).
+
+:::caution
+
+Each User Power Port (Molex 0039301040) has a shared ground (GND) pin with a maximum current rating of 8 A. Ensure
+that the combined current draw for the VBAT, 12V, and 5V pins for the corresponding GND
+pin does not exceed 8 A.
+
+:::
+
+#### MCU Debug LEDs
+
+The Jackal MCU circuit board comes equipped with four LEDs controlled by Jackal firmware for debugging.
+If the system is working properly, these LEDs functions as follows:
+
+- **DBG1**: toggles every 500 ms when main loop on MCU is running
+- **DBG2**: not used in normal operation; LED should be off
+- **DBG3**: not used in normal operation; LED should be off
+- **DBG4**: not used in normal operation; LED should be off
+
+### Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../accessories/computers/computers.mdx)
+- [Sensors](../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/jackal/maintenance_jackal.mdx b/docs/robots/outdoor_robots/jackal/maintenance_jackal.mdx
new file mode 100644
index 000000000..f830e6275
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/maintenance_jackal.mdx
@@ -0,0 +1,27 @@
+---
+title: Jackal Maintenance
+sidebar_label: Maintenance
+sidebar_position: 4
+---
+import ClearpathFirmware from "../../../components/_clearpath_firmware.mdx";
+import ComponentIntroductionJackal from "/components/introduction_jackal.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/jackal/troubleshooting_jackal.mdx b/docs/robots/outdoor_robots/jackal/troubleshooting_jackal.mdx
new file mode 100644
index 000000000..b40fdd219
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/troubleshooting_jackal.mdx
@@ -0,0 +1,54 @@
+---
+title: Jackal Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 5
+---
+
+import ComponentIntroductionJackal from "/components/introduction_jackal.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../accessories/sensors/sensors.mdx).
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/outdoor_robots/jackal/tutorials_jackal.mdx b/docs/robots/outdoor_robots/jackal/tutorials_jackal.mdx
new file mode 100644
index 000000000..f09679c62
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/tutorials_jackal.mdx
@@ -0,0 +1,35 @@
+---
+title: Jackal Tutorials
+sidebar_label: Tutorials
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionJackal from "/components/introduction_jackal.mdx";
+import ComponentTutorialLinks from "../../../components/_tutorials_link.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Jackal Overview
+
+### Introduction
+
+Jackal is a rugged, lightweight, fast and easy-to-use unmanned ground robot for rapid prototyping
+and research applications. These tutorials will assist you with setting up and operating your Jackal.
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/jackal).
+
+
+
+## Jetson Installation
+
+Refer to the [Jetson](../../accessories/computers/jetson/jetson_hardware/jetson_hardware.mdx) page for details on installing a Jetson in Jackal.
+However, at present, ROS 2 software is not supported on Jetson in Jackal.
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/jackal/user_manual_jackal.mdx b/docs/robots/outdoor_robots/jackal/user_manual_jackal.mdx
new file mode 100644
index 000000000..a7b2aa30e
--- /dev/null
+++ b/docs/robots/outdoor_robots/jackal/user_manual_jackal.mdx
@@ -0,0 +1,361 @@
+---
+title: Jackal User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionJackal from "/components/introduction_jackal.mdx";
+import Support from "/components/support.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+import ComponentSafetyWarning from "/components/safety_warning.mdx";
+
+
+
+## Introduction
+
+Jackal is a rugged, lightweight, fast and easy-to-use unmanned ground robot for rapid prototyping
+and research applications. Jackal includes a computer, as well as basic IMU and GPS. Standard
+perception modules are available, including URDF, simulator integration, and demonstration
+applications.
+
+
+
+### Shipment Contents
+
+Your Jackal shipment contains the following:
+
+- Clearpath Robotics Jackal
+- 270 Wh lithium battery
+- 110 VAC - 220 VAC battery charger
+- Sony PS4 Bluetooth controller
+
+If you purchased standard payload modules or custom integration services with Jackal, then additional
+equipment will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Jackal is built around a computer running Ubuntu (Intel-based computer or Jetson developer kit), paired
+with a 32-bit microcontroller MCU. The MCU handles IO, power supply monitoring and motor control, as well as supplying
+data from the integrated IMU and GPS receiver. The communication channel between the MCU and computer is a Full
+Speed USB connection, with the MCU operating as a standard serial CDC device.
+
+The communication protocol used is rosserial. An instance of the `rosserial_server` serial node is embedded
+in the `jackal_base` node, where it is connected to Jackal's kinematic controller.
+
+An internal magnetometer is available, but not recommended for use due to its location in the vehicle chassis.
+
+#### Exterior Features
+
+The Jackal exterior is shown below and includes:
+
+- 80 mm mounting pattern on the lid
+- 194 mm diameter wheels
+- Human machine interface panel (HMI)
+- Lid latches
+
+
+
+#### Human-Machine Interface (HMI) Details
+
+
+
+The human-machine-interface (HMI) panel is shown below and includes from left:
+
+| Icon | Description |
+| :---------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| | **Motion Stop button**: LED is solid green when Jackal is able to drive and flashing green when the Jackal's motors are disengaged; pressing button toggles the motors between engaged and disengaged mode (further details in [Motion Stop Buttons](#jackal-stop-buttons)) |
+| | **Comms indictor**: LED is solid green when communication between the MCU and computer has been established and LED is off otherwise |
+| | **Wi-Fi indicator**: LED is solid green when Wi-Fi is connected and LED is off otherwise |
+| | **Battery indicator**: LED is solid green when the battery level is ok, solid yellow when the battery level is getting low (should be charged soon), and solid red when the battery level is critical (should be charged immediately) |
+| | **System Power button**: LED is solid blue when the system is powered on and running and the LED is flashing blue during the shutdown process; when the system is powered off, pressing the power button begins the power on process; when the system is powered on, a quick press of the power button begins a graceful shutdown and a prolonged press of the power button triggers and immediate power off of the system |
+
+
+
+
+ HMI Panel
+
+
+
+#### Payloads
+
+Additional payloads such IMUs, lidars, cameras, GPS, manipulators and many more can be integrated
+with Jackal, either as part of your Jackal purchase or installed after receiving your Jackal.
+You can find a list of supported packages and related documentation for payloads in this
+documention portal, under the [Computers](../../accessories/computers/computers.mdx),
+[Sensors](../../accessories/sensors/sensors.mdx), [Manipulators](../../accessories/manipulators/manipulators.mdx),
+and [Accessories](../../accessories/add-ons/add-ons.mdx) sections. In addition, refer to [Jackal Integration](integration_jackal.mdx) for
+details on how to integrate your own payload or how to integrate a payload kit from Clearpath Robotics.
+Each payload kit that ships from Clearpath Robotics comes with a custom mounting bracket and cabling for
+easy attachment to Jackal.
+
+#### Interior Features
+
+To access Jackal's interior, actuate the latches under the front end of the lid, on the opposite end from
+the HMI. When you lift the lid, you will see Jackal's onboard lithium battery, and its two connectors.
+The large Anderson Power Pole connector is to supply power to Jackal and must be connected for
+Jackal to operate. The smaller white Molex connector allows the battery to be charged inside Jackal
+while Jackal is powered off. It is recommended to connect both. The interior components of Jackal are
+labeled below.
+
+
+
+
+ Battery area inside Jackal
+
+
+
+Further, you may undo the thumbscrews which hold Jackal's computer tray to the lid. The tray lowers,
+revealing Jackal's onboard computer, user power supplies, and internal user hardware mounting area.
+The figures below illustrate the components of the tray and user power supplies.
+Note that the fused user power is available as four-pin Molex connectors, or a plug-in screw terminal
+block. For more information on integrating payloads electrically, see
+[Jackal Integration](integration_jackal.mdx#jackal-payload-electrical-integration).
+
+
+
+
+ Computer and user tray
+
+
+
+
+
+
+ User power supply
+
+
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855.
+
+
+
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be
+taken to ensure that data is interpreted correctly.
+
+
+
+### System Specifications
+
+| Specification | Measurement |
+| :-------------------- | :----------------------------------------------------------------------- |
+| Dimension, Length | 508 mm |
+| Dimension, Width | 430 mm |
+| Dimension, Height | 250 mm |
+| Ground Clearance | 65 mm |
+| Maximum Payload | 20 kg |
+| Speed, Maximum | 2.0 m/s |
+| Battery Chemistry | Lithium, 270 Wh |
+| Operating Time | 8 hours (basic usage), 2 hours (heavy usage) |
+| Charge Time | 4 hours |
+| User Power | 16 A @ VBAT (25.6 V nominal), 7 A @ 12 V, 5 A @ 5 V |
+| Communication | Ethernet, USB 3.0 |
+| Internal Sensing | Battery Status, Wheel Odometry, Motor Currents, Onboard IMU, Onboard GPS |
+| Operating Temperature | -19 to 45 °C |
+| Operating Environment | Indoor or Outdoor (designed for IP62) |
+
+
+
+
+
+---
+
+## Getting Started
+
+You are ready to go! This section details how to get Jackal into action.
+To begin, place Jackal "up on blocks" as described in the [Safety](#safety) section, making sure that the wheels are clear of the ground.
+
+For most Jackal setups, there will be an Onboard Computer which is directly connected to the Jackal and an Offboard Computer
+which is used to control Jackal and gather data. These two computers must be set up to communicate with each other.
+
+### Onboard Computer Setup
+
+If you purchased an Onboard Computer from Clearpath Robotics with Jackal, it is already installed, connected, and powered.
+If not, or to set up your own Onboard Computer, see the
+[Jackal Tutorials](tutorials_jackal.mdx).
+
+Note that the Onboard Computer must be connected to the USB port on the Jackal MCU, which is accessible inside the Jackal.
+
+### Powering Up
+
+If you've just unpacked Jackal from its packaging, you may need to open it up and connect the battery.
+
+Press the power button on Jackal's HMI panel.
+The LEDs should show a test pattern, after which you will wait about 30 seconds for the internal computer to finish booting up.
+Once it has finished booting, the Comms indicator should turn green.
+This indicates that ROS is up on the computer and has established communications with the Jackal base.
+
+### Network Configuration
+
+To get Jackal connected to your local Wi-Fi network, you must first access the Onboard Computer using a wired connection to the robot.
+Open the chassis, lower the computer tray, and connect to the network port labeled STATIC with a standard
+ethernet cable. See the [Jackal Tutorials](tutorials_jackal.mdx) for details
+on completing the Wi-Fi setup.
+
+### Connecting and Using the Controller {#controller}
+
+To use your controller, it must be paired with your Jackal and powered on.
+If your purchased the Onboard Computer from Clearpath Robotics, your controller is already paired with your Jackal.
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in
+the [Jackal Tutorials](tutorials_jackal.mdx).
+
+To teleoperate Jackal, first clear the motion-stop.
+Then, power on the controller by pressing the `PS` button on the controller.
+Once the blue LED on the top of the controller goes solid, you are paired and ready to drive.
+Hold the L1 trigger button (deadman switch) and push the left thumbstick forward to drive the Jackal.
+For full speed mode, hold the R1 trigger.
+See the figure below for the Sony PS4 controls layout.
+If you are not seeing any action, refer to [Support](#jackal-support) to get in touch with support.
+
+
+
+
+ PS4 Controls Layout
+
+
+
+### Using ROS
+
+
+
+### Battery Charging
+
+When finished with the Jackal, press and release the power button to power it off.
+
+Jackal's lithium battery may be charged internal to the chassis: simply plug in
+the charger to the charge port located under the rear fender. Charging will occur
+when Jackal is powered down.
+
+Alternatively, if you have multiple batteries, you can easily lift the lid and
+remove the battery for external charging. When charging externally, remove the pigtail
+which adapts the charger to the platform's weather sealed charge port.
+
+The battery is manufactured for Clearpath Robotics by AllCell Technologies. The
+pack includes integrated protections against fault due to overcurrent, overdischarge,
+and short circuit. The pack is rugged and designed for the demanding environments into
+which Jackal may be deployed.
+
+However, please take note of the following:
+
+- The pack must not be stored or operated above +60 °C or below -19 °C.
+- The pack must not be punctured or disassembled.
+- The pack should be dropped off or delivered to your local hazardous waste authority for disposal.
+- When traveling with Jackal, consult your airline's restrictions regarding lithium
+ batteries. If possible, bring the pack in your carry on luggage, where it will
+ be subject to normal cabin temperatures and pressures.
+
+Please contact Clearpath Robotics for additional information about Jackal's battery or
+for information about purchasing additional packs.
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+Jackal contains several features to protect the safety of users and the integrity of the robot.
+
+:::caution
+
+Jackal is a fast moving robotic platform. Please read the following notices carefully.
+
+:::
+
+### General Warnings
+
+Jackal is a rugged and high-performance robot.
+For the safety of yourself and others, always conduct initial experiments and software development with
+the robot raised off the ground. Place a wooden crate, a set of sawhorses, a sturdy storage tub, or any
+other solid flat structure having a height greater than 100 mm under Jackal to keep the wheels clear of the
+ground ("up on blocks").
+
+When starting out, favour slower wheel speeds. Jackal's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+### Motion Stop Buttons {#jackal-stop-buttons}
+
+The Motion Stop button is located on the HMI Panel at the back of Jackal.
+To engage Stop Mode, press the Motion Stop button once; you should see that the green LED by the Motion Stop button is flashing and that all four corner LEDs are flashing red.
+To disengage Stop Mode, press the Motion Stop button again; all LEDs should return to their original values.
+
+When in Stop Mode, the Jackal will not drive.
+The commands received while in Stop Mode are not buffered; Jackal will always act on the latest commands received.
+This means that if the commands are stopped before the Motion Stop button is pressed to disengage Stop Mode, the Jackal will not move.
+If the commands are continued, Jackal will move at the speed commanded once the Motion Stop button is pressed to disengage Stop Mode.
+
+Ensure that the Motion Stop button is accessible at all times.
+Avoid mounting payloads that extend over the rear of Jackal and would block access to the Motion Stop button.
+
+### Electrical System
+
+Jackal is powered by batteries capable of delivering high outputs for short durations.
+This gives Jackal's motors their great performance; however, it is also enough power to cause severe bodily harm.
+Always use caution when operating Jackal to avoid personal injury or property damage.
+To ensure safety, please observe the following precautions:
+
+- Do not tamper with the plug attached to the battery.
+- Do not tamper with the fuses, except to check and change the fuses.
+- Always replace fuses with the same type and rating to ensure continued protection against risk of fires.
+- Consult Clearpath Robotics support if you need to service the batteries.
+- Charge the battery only with the charger provided by Clearpath Robotics.
+- Please dispose of the batteries properly or return them to Clearpath Robotics to do so.
+
+### Lifting and Transport
+
+For the safety of users and to maximize the lifetime of Jackal, please observe the following when manually transporting the robot:
+
+- Ensure that Jackal's Stop Mode is engaged when transporting short distances and powered off when transporting longer distances.
+- Do not push the robot at more than 0.5 m/s (1.6 ft/s) or damage to the motor controls may occur.
+
+### Performance Considerations
+
+Included in Jackal are native software checks and limits to protect the robot.
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+### Recommended Safe Work Procedures
+
+
+
+---
+
+## Support {#jackal-support}
+
+
diff --git a/docs/robots/outdoor_robots/warthog/_category_.json b/docs/robots/outdoor_robots/warthog/_category_.json
new file mode 100644
index 000000000..54966dd03
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Warthog",
+ "position": 1
+}
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/_category_.json b/docs/robots/outdoor_robots/warthog/integration_warthog/_category_.json
new file mode 100644
index 000000000..e5f1838f9
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Integration",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/integration_warthog.mdx b/docs/robots/outdoor_robots/warthog/integration_warthog/integration_warthog.mdx
new file mode 100644
index 000000000..fb4baf658
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/integration_warthog.mdx
@@ -0,0 +1,155 @@
+---
+title: Warthog Integration
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentPacsMechanical from "/components/pacs_mechanical.mdx";
+import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
+import Support from "/components/support.mdx";
+
+To attach custom hardware to Warthog, you will have to take care of mechnical mounting, electrical supply, and software integration.
+This section aims to equip you with respect to these challenges.
+
+---
+
+## Mechanical {#warthog-mechanical-mounting}
+
+When determining mechanical mounting, you have two options, both of which are described below.
+
+- the "Standard" aluminum extrusion interface
+- the "PACS™" mounting system and associated kits
+
+### Mechanical, Standard
+
+A standard Warthog includes thru holes on the sides of the battery compartment.
+You can besign mounting brackets to interface with these holes.
+
+### Mechanical, PACS™
+
+
+
+Refer to the following pages for Warthog brackets that can simplify your integration.
+
+- [Extrusion Rails](kits_warthog/extrusion_rails_warthog.mdx)
+- [Extrusion Cross-Bar](kits_warthog/extrusion_crossbar_warthog.mdx)
+- [Top Plate](kits_warthog/top_plate_warthog.mdx)
+
+### Common Mechanical Integration Guidelines
+
+- 705 mm (27.75") is the maximum allowed width of any installed payload (this assumes that the payload is also centered across the width of the UGV chassis.
+- No part of the payload may extend over the sheet metal housings of the drive units or into the small 50 mm (2") gaps between the chassis and drive units.
+ Damage to both the UGV and the payload will result.
+- The chassis has a removable access cover measuring 1175 mm X 667 mm (46.25" X 26.25").
+ This access cover is supported underneath by two adjustable cross members.
+ Regardless of payload, it is imperative that both cross members remain installed (approximately evenly spaced) to provided required support to the access cover.
+ Consider that any payload installed above the top deck will prevent access to the chassis through the access cover, without first removing the installed payload.
+- The rotation of the suspension differential link in the horizontal plane will allow the payload to extend beyond the chassis top deck in both fore and aft locations.
+ The amount of this payload extension (overhang) is dependent on several factors, including the weight and method of attachment of the payload as well as the terrain in which the UGV will operate.
+ Ensure that the amount of overhanging payload allows the UGV to operate safely and does not contact the terrain, especially when crossing steep and/or deep gullies.
+- The available internal chassis volume is:
+ - Length of 445 mm (17.5")
+ - Width of 660 mm (26")
+ - Height of 241 mm (9.5").
+ This space is located at the center of the chassis between two battery packs.
+ Consider that anything placed inside the chassis must be secured as to not move or shift during UGV operation.
+
+:::caution
+
+Permanent damage resulting from custom modifications to the mounting plate is not covered under warranty and may not be supported by Clearpath Support.
+Please contact our Support team if you require assistance or have any questions relating to custom modifications.
+
+:::
+
+---
+
+## Electrical Integration {#warthog-electrical-integration}
+
+:::danger
+
+For continued protection against risk of fire, only replace fuses with those of the same type and rating.
+
+:::
+
+Except for bus-powered USB cameras, most payloads have separate leads for power and data.
+
+### Top Plate Power and Data Connections Connections
+
+| Description | Notes | Mating Connector (CPR Item) | Mating Connector (Manufacturer Item) |
+| :------------------------------------------------------ | :-------------------------------------- | :-------------------------- | :---------------------------------------------------------------------------------------- |
+| [USER POWER](/assets/pdf/clearpath_robotics_014673.pdf) | 12 V, 24 V, 48 VBAT; each fused to 10 A | 015016 | [RR-153274-23050](https://www.usbfirewire.com/parts/rr-153274-23050.html#RR-153274-23050) |
+| USB 3.0 | | | Male USB type-A |
+| ETHERNET RJ45 | | | Male RJ45 |
+| [SERIAL](/assets/pdf/clearpath_robotics_014672.pdf) | | 015015 | [RR-153274-23040](https://www.usbfirewire.com/parts/rr-153274-23040.html#RR-153274-23040) |
+
+
+
+
+ Warthog user panel
+
+
+
+
+
+
+ Warthog connector pinouts
+
+
+
+The user power receptacles located in the User Panel are capable of supplying 12 VDC, 24 VDC, and unregulated battery voltage (48 - 60 VDC) for powering Warthog's payloads.
+See the figures below for connector locations and pinouts.
+Ensure you select a contact that's appropriate for the gauge of wire used.
+
+:::note power
+
+The user power breakouts are intended for small sensors, like lidar and cameras.
+Warthog's 48 V battery pack is fused at 275 A (13200 W).
+We often add DC-DC and DC-AC supplies inside the Warthog to power large devices like manipulators, lights, and other custom integration attachments.
+
+Refer to the process described on our [Power Supplies](../../../accessories/add-ons/power_supplies.mdx#choosing_a_power_supply) page to help you choose a power supply or inverter.
+
+:::
+
+:::danger
+
+Always use adequately sized fuses for your selected wire thickness to prevent electrical fires.
+
+:::
+
+### System Electrical Diagram
+
+
+
+
+ Warthog chassis electrical system
+
+
+
+---
+
+## Software Integration
+
+
+
+Refer to the following for more details:
+
+- [Computers](../../../accessories/computers/computers.mdx)
+- [Sensors](../../../accessories/sensors/sensors.mdx)
+- [Manipulators](../../../accessories/manipulators/manipulators.mdx)
+- [Accessories](../../../accessories/add-ons/add-ons.mdx)
+
+---
+
+## Support
+
+
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/_category_.json b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/_category_.json
new file mode 100644
index 000000000..cc3b026a7
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Kits",
+ "position": 3
+}
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
new file mode 100644
index 000000000..0918b81b8
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
@@ -0,0 +1,92 @@
+---
+title: Extrusion Cross-Bar
+sidebar_position: 2
+---
+
+
+
+
+
+This is a 25 mm X 50 mm aluminum extrusion that mounts between the Warthog's [Extrusion Rails](extrusion_rails_warthog.mdx).
+The Cross-Bar is installed with T-slot nuts and 90° brackets.
+The Cross-Bar can be attached anywhere along the length of the Warthog's Extrusion Rails.
+
+## Sales Kits
+
+:::note
+
+This kit requires a Warthog with Extrusion Rails.
+Refer to the [Extrusion Rails](extrusion_rails_warthog.mdx) page for further details.
+
+:::
+
+| Description | Sales Kit |
+| :--------------------------------------------- | :-------: |
+| Installation—Extrusion Cross-Bar, 25 X 50, 652 | 028455 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :--------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1 | Beam, T-slot—25 X 50, 655, Aluminum, Black | [028465](/assets/pdf/clearpath_robotics_028465-TDS1.pdf) | 1 |
+| 2 | Bracket, T-Slot, 90°—5.8, 20, Aluminum, Black | [028464](/assets/pdf/clearpath_robotics_028464-TDS1.pdf) | 8 |
+| 3 | Nut, T-Slot—M5×0.8 X 5.8 X 10, Steel | [028463](/assets/pdf/clearpath_robotics_028463-TDS1.pdf) | 32 |
+| 4 | Screw, Cap, Socket Head—M5×0.8 X 10, Stainless Steel | 023150 | 32 |
+
+## Tools required
+
+- Hex Key, 4 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Attach 8 Brackets _(ID2)_ to the ends of the Beam _(ID1)_.
+Use 2 T-slot Nuts _(ID3)_ and 2 Screws _(ID4)_ per Bracket.
+
+:::note
+
+Torque these screws to 5 N·m if you are concerned about them loosening from high vibration applications.
+
+:::
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 2
+
+Add a T-slot Nut _(ID3)_ and Screw _(ID4)_ to each of the remaining holes of the Brackets _(ID2)_.
+Leave these Screws loose, in anticipation of the next step.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
+
+### Step 3
+
+Slide the Cross-Bar assembly between the Warthog's Extrusion Rails.
+Make sure all 16 of the loose T-slot nuts are guided into the Extrusion Rails.
+
+### Step 4
+
+Slide the Cross-Bar assembly to your intended final position on the Warthog per your application.
+
+### Step 5
+
+Tighten all 16 Screws.
+
+:::note
+
+Torque these screws to 5 N·m if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
new file mode 100644
index 000000000..8aacdf691
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
@@ -0,0 +1,123 @@
+---
+title: Extrusion Rails
+sidebar_position: 1
+---
+
+
+
+
+
+This kit adds [25 mm X 50 mm aluminum extrusions](/assets/pdf/clearpath_robotics_028459-TDS1.pdf) to both sides of the Warthog.
+The extrusions are attached to the Warthog using M6×1 stainless steel screws, and [stainless steel rivets](https://www.mcmaster.com/97525A247/) with a Ø5 mm shank.
+
+You can attach your own custom brakets to the extrusions using M5×0.8 T-slot nuts, or these other useful off-the-shelf items:
+
+| Description | CPR Item | Manufacturer | Manufacturer Item |
+| :-------------------------------------------- | :------------------------------------------------------: | :----------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Nut, T-Slot—M5×0.8 X 5.8 X 10, Steel | [028463](/assets/pdf/clearpath_robotics_028463-TDS1.pdf) | Misumi | [HNTTSS5-5](https://us.misumi-ec.com/vona2/detail/110302246150/?HissuCode=HNTTSS5-5&PNSearch=HNTTSS5-5&searchFlow=results2type&KWSearch=HNTTSS5-5) |
+| Bracket, T-Slot, 90°—5.8, 20, Aluminum, Black | [028464](/assets/pdf/clearpath_robotics_028464-TDS1.pdf) | Misumi | [HBLFSSWB5](https://us.misumi-ec.com/vona2/detail/110300437350/?HissuCode=HBLFSSWB5&PNSearch=HBLFSSWB5&searchFlow=results2type&KWSearch=HBLFSSWB5) |
+| Bracket, Flat, 90°—Stainless Steel | | Misumi | [SHPTUL5](https://us.misumi-ec.com/vona2/detail/110302245810/?HissuCode=SHPTUL5&PNSearch=SHPTUL5&searchFlow=results2type&KWSearch=SHPTUL5) |
+| Beam, T-slot—25 X 25, Aluminum, Black | Configurable Lengths | Misumi | [HFSB5-2525](https://us.misumi-ec.com/vona2/detail/110302685050/?HissuCode=HFSB5-2525&PNSearch=HFSB5-2525&searchFlow=results2type&KWSearch=HFSB5-2525) |
+| Beam, T-slot—25 X 50, Aluminum, Black | Configurable Lengths | Misumi | [HFSB5-2550](https://us.misumi-ec.com/vona2/detail/110302685140/?HissuCode=HFSB5-2550&PNSearch=HFSB5-2550&searchFlow=results2type&KWSearch=HFSB5-2550) |
+
+Misumi also offers a range of configurable products that can help with your integration.
+
+Please email \ if you want Clearpath's team to design a bracket structure for your application.
+
+---
+
+## Sales Kits
+
+| Description | Sales Kit |
+| :------------------------------------ | :-------: |
+| Installation—Extrusion, 25 X 50, 1217 | 028454 |
+
+## Parts List
+
+| ID | Description | CPR item | Manufacturer Item | Quantity |
+| :-: | :-------------------------------------------------------------- | :-------------------------------------------------: | :----------------------------------------------- | :------: |
+| 1 | Block—76.2 X 25.4 X 25.4 X M10×1.5 | [028452](/assets/pdf/clearpath_robotics_028452.pdf) | | 8 |
+| 2 | Insert, Thread, Adhesive—M6×1 X M10×1.5 X 10.5, Stainless Steel | 028458 | [97120A230](https://www.mcmaster.com/97120A230/) | 8 |
+| 3 | Beam, T-slot—25 X 50, 1217, Aluminum, Black | [028459](/assets/pdf/clearpath_robotics_028459.pdf) | | 2 |
+| 4 | Rivet, Blind, Dome—Ø5 X 20 - 25, Stainless Steel | 028460 | [97525A247](https://www.mcmaster.com/97525A247/) | 16 |
+| 5 | Screw, Cap, Socket Head—M6×1 X 35, Stainless Steel | 023186 | [92290A334](https://www.mcmaster.com/92290A334/) | 8 |
+
+## Tools Required
+
+- Drill, with Ø6 mm drill bit
+- Rivet installation tool (Refer to our [Physical Tools](../../../../common/physical_tools.mdx) page for a suggested rivet installation tool)
+- Large flat-head screwdriver, or a thread insert installation tool
+- Hex Key, 5 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Use the drill to remove the 16 existing rivets on the top deck of the Warthog.
+You can use the Extrusion Beam _(ID3)_ as a reference of what rivets to remove.
+
+:::caution
+
+Just remove the rivet's head with the drill.
+We do not want to enlarge the holes in the Warthog's frame.
+
+:::
+
+:::note
+
+This kit only includes 4 Blocks _(ID1)_ per Beam.
+You can install up to 7 Blocks per beam if your application requires a stiffer base.
+
+:::
+
+:::note
+
+Part of the rivet will fall into the Warthog's steel tube frame.
+We intend for you to leave these scrap bits of rivet within the Warthog's frame.
+
+:::
+
+### Step 2
+
+Place the Blocks _(ID1)_ above the holes where you had removed the rivets.
+
+### Step 3
+
+Insert the new Rivets _(ID4)_ through the Blocks _(ID1)_ and into the Warthog's frame.
+
+### Step 4
+
+Fasten the rivets using your rivet installation tool.
+
+### Step 5
+
+Install a Thread Insert _(ID2)_ into each of the Blocks _(ID1)_ using your standard screwdriver or thread insert installation tool.
+Make sure the installed Thread Inserts are below the top surface of the Blocks.
+
+### Step 6
+
+Place the two Beams _(ID3)_ onto the Warthog's Blocks _(ID1)_.
+
+:::info notice
+
+Notice that the Beams have a small diameter hole on one side, and a larger diameter hole on the other side.
+The small holes face down, the large holes face up.
+
+:::
+
+### Step 7
+
+Install a Screw _(ID5)_ into each of the Blocks _(ID1)_.
+This will fasten the Beams _(ID3)_ onto the Warthog.
+Torque these screws to 5 N·m.
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
new file mode 100644
index 000000000..e1ad6c6fd
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
@@ -0,0 +1,82 @@
+---
+title: Top Plate
+sidebar_position: 3
+---
+
+
+
+
+
+The top plates for the Warthog include M5×0.8 threaded holes that match the Clearpath PACS™ standard.
+
+---
+
+## Sales Kits
+
+:::note
+
+This kit requires a Warthog with Extrusion Rails.
+Refer to the [Extrusion Rails](extrusion_rails_warthog.mdx) page for further details.
+
+:::
+
+:::tip
+
+This Top Plate can be stiffened by adding a Crossbar underneath it.
+Refer to the [Crossbar](extrusion_crossbar_warthog.mdx) page for further details.
+
+:::
+
+| Description | Sales Kit |
+| :---------------------------------------------- | :-------: |
+| Installation, Kit, Attachment Top Plate—Warthog | 028462 |
+
+## Parts List
+
+| ID | Description | CPR item | Quantity |
+| :-: | :--------------------------------------------------- | :------------------------------------------------------: | :------: |
+| 1 | Plate—110 X 704.5 | [028451](/assets/pdf/clearpath_robotics_028451.pdf) | 1 |
+| 2 | Nut, T-Slot—M5×0.8 X 5.8 X 10, Steel | [028463](/assets/pdf/clearpath_robotics_028463-TDS1.pdf) | 9 |
+| 3 | Screw, Flat Head—M5×0.8 X 12, Stainless Steel | 023471 | 3 |
+| 4 | Screw, Cap, Socket Head—M5×0.8 X 12, Stainless Steel | 023151 | 6 |
+
+## Tools required
+
+- Hex Key, 3 mm
+- Torque wrench _(optional, for safety applications)_
+- Loctite 243 _(optional, for high vibration applications)_
+
+## Installation
+
+### Step 1
+
+Insert T-slot nuts _(ID2)_ into the Warthog's [Extrusion Rail](extrusion_rails_warthog.mdx) and [Cross-Bar](extrusion_crossbar_warthog.mdx).
+
+:::note
+
+You may need to loosen the Cross-Bar's brackets to get access to the end for inserting the T-slot nuts.
+
+:::
+
+### Step 2
+
+Place the Plate _(ID1)_ ontop of the Extrusion Rails and Crossbar. The Plate's countersink features should be facing up.
+
+### Step 3
+
+Install Screws _(ID3)_ and _(ID4)_ into the Plate's holes; threading the Screws into the T-slot nuts from _Step 1_.
+
+:::note
+
+Torque these screws to 5 N·m if you are concerned about them loosening from high vibration applications.
+
+:::
+
+:::note
+
+You may add a small amount of thread locker to these screws if you are concerned about them loosening from high vibration applications.
+
+:::
diff --git a/docs/robots/outdoor_robots/warthog/maintenance_warthog.mdx b/docs/robots/outdoor_robots/warthog/maintenance_warthog.mdx
new file mode 100644
index 000000000..205559151
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/maintenance_warthog.mdx
@@ -0,0 +1,193 @@
+---
+title: Warthog Maintenance
+sidebar_label: Maintenance
+sidebar_position: 5
+---
+import ClearpathFirmware from "../../../components/_clearpath_firmware.mdx";
+import ComponentIntroductionWarthog from "/components/introduction_warthog.mdx";
+import GettingNewPackages from "/components/maintenance/getting_new_packages.mdx";
+import Support from "/components/support.mdx";
+
+
+
+---
+
+## Battery and Charging
+
+### Overview
+
+Warthog contains a 48 V lead-acid battery pack, consisting of four 12 V lead-acid batteries, or a LiFEPO4 battery pack, consisting of four 118 Ah 12.8 V batteries
+connected in a 4S1P configuration with a single Battery Management System (BMS) control unit. Battery configuration may vary with each unit. In order to
+maximize performance, it's important to ensure that the battery level across each set of lead-acid or LiFEPO4 batteries is within 0.1-0.2 V.
+If the batteries exceed this tolerance, it's advised to charge them to within tolerance before wiring these packs in parallel. The overall battery life
+will vary depending upon the usage of the unit. The typical lifetime of a lead-acid battery pack is approximately 250-300 charge/discharge cycles,
+depending on the depth of discharge.
+
+### Battery Management System
+
+:::note
+
+If your Warthog is equipped with a lead-acid battery pack, you can ignore this section on the Battery Management System.
+
+:::
+
+:::note
+
+Your charger must be disconnected completely from the Warthog when not charging the unit. Leaving the cable plugged
+into the Warthog enables the BMS system to be powered on fully even when the robot is off, which will cause the
+batteries to be drained to an over-discharged state.
+
+:::
+
+If your Warthog is equipped with a LiFEPO4 battery pack, it is also equipped with a single Battery Management System (BMS) control unit.
+The main function of the BMS is to:
+
+- Protect the individual modules from being overcharged or excessively discharged.
+- Protect the modules from operating outside of their acceptable temperature range.
+- Provide status information to higher level systems via a CAN interface.
+- Provide independent system management without a higher level control system.
+- Provide status, warning and error messages from each of the modules connected to the battery power system.
+- Control the charging operation.
+- Perform module to module balancing of the system, the battery module will control cell balancing within itself.
+
+There is a main power contactor which is controlled by the BMS unit and is placed in such a way that it controls all power to the system.
+Upon turning on the main disconnect switch:
+
+The BMS powers up first and begins communicating with all of the battery modules in the system.
+
+1. If they are all present and have no errors the BMS will close the main contactor and allow the Warthog to power up as normal,
+ this process can take a few seconds before the main contactor closes.
+ - If all the modules are not present, the system State of Charge (SOC) is too low, or there are errors being reported by any of the
+ modules in the system, the contactor will not close, and the system will not power up.
+2. Similarly, if a user is in discharge mode (the Warthog is in use) and any errors are detected, or if the SOC falls to a cut off point,
+ the contactor will open and remove power from the system to protect the modules.
+ - It is not good practice to run the state-of-charge (SOC) to 0%. This will decrease the life of the battery module. In general, keeping the SOC to a
+ minimum of 30-50% can increase the lifetime of the batteries.
+ - As a note, the system SOC is identical to the module with the lowest SOC in the system, so if three modules are at 45% SOC, and
+ one module is at 25%, then the SOC of the system is 25%, and the BMS will act accordingly cutting off power to protect the module with
+ the lowest SOC. Cell balancing and proper charging techniques are important to maintaining good battery health.
+3. The Warthog can be charged when the unit is powered and running, and can also be charged when the unit is not powered (main disconnect switch is open).
+ - The charger has been configured and wired in a way that the BMS is actually controlling the charger and can turn it off, and on, depending
+ on the status of the charging cycle.
+ - Even though the unit can be charged while running, this process does not allow for proper cell balancing to occur. It will allow for bulk charge
+ to occur to regain most of the charge in the system, however, repeatedly charging in this manner will allow each module to become out of balance with
+ the other modules. If this process if followed long enough the SOC values for each module can vary by a substantial amount. The larger the variation,
+ the longer it will take to fully balance the system. Therefore it is recommended (depending on use) that at least once every two to three weeks that
+ **the system be completely charged while the main disconnect switch is in the off position.** Doing so will allow the BMS to go through an
+ equalization phase where the charger is being turned on and off by the BMS to balance the voltages across each cell layer, in each module across the system.
+ **This is a very important step in maintain battery health, and getting the maximum lifetime out of the battery system.**
+ - Refer to [BMS ROS Topics](#bms-ros-topics) to view the necessary topics through the ROS API.
+4. To allow for this level of control there are three contactors in the system:
+ - The main contactor for discharge of the system.
+ - The charge contactor to connect to the output of the charger.
+ - The charge control relay to turn the charger outputs on and off and control the cell balancing or equalization phase of the charge cycle.
+
+#### BMS ROS Topics {#bms-ros-topics}
+
+:::note
+
+If your Warthog is equipped with a lead-acid battery pack, you can ignore this section on the BMS ROS Topics.
+
+:::
+
+The table below shows topics that will be very useful in monitoring battery health, as outlined in the section above.
+
+| Topic | Purpose |
+| :------------------------- | :--------------------------------------------- |
+| `/bms/system_status` | Primarily to view `state_of_charge` (%) |
+| `/bms/system_measurements` | Primarily to view `battery_system_current` (A) |
+
+Note that the `battery_system_current` topic will be positive when the batteries are charging, indicating that
+current is flowing into the batteries. The lights on the charger unit itself will also indicate when the device is
+charging.
+
+#### To Connect the Charger
+
+1. Plug in the charger DC output cable (heavier gauge cable).
+2. Plug in the charger auxiliary control cable. (Note: Only relevant to Warthogs with LiFEPO4 batteries.)
+3. Plug the charger into AC power (directly to the wall outlet, no extension cords).
+4. This can be done with or without power on Warthog being on (however the note above applies: at least once every 2-3 weeks, the charge
+ process needs to be allowed to fully balance the system).
+
+#### To Disconnect the Charger
+
+1. Unplug the charger from AC power.
+2. Unplug the charger auxiliary cable.
+3. Unplug the charger DC output cable (heavier gauge cable).
+
+#### Battery Pack Specifications
+
+Key battery system specifications are listed in the table below.
+
+| Specification | Measurement |
+| :-------------------------------- | :---------------------------------- |
+| System Voltage ( nominal ) | 51.2V ( up to 59 V while charging ) |
+| System Capcity | 118 Ah |
+| System Energy | 6.041 kWh |
+| Continuous Discharge Current | 150 A |
+| Peak Discharge Current ( 30 sec ) | 300 A |
+| Discharge Temperature Range | -10 °C to 50 °C |
+| Charge Temperature Range | 0 °C to 45 °C |
+
+### General Battery Safety and Maintenance
+
+Always exercise caution and observe the following safety practices when connecting, disconnecting or handling batteries:
+
+- Batteries are high voltage, high current.
+- Batteries must be properly fastened down to ensure they do not move when the Warthog is in operation.
+- Ensure that the batteries are evenly distributed throughout the Warthog to maximize stability.
+- Battery levels on the unit should be checked on a regular basis.
+ It's important to maintain the battery voltage at a suitable level for proper operation.
+
+### Long-term Storage
+
+When storing Warthog for long periods of time, it's important to properly maintain the batteries to fully maximize their life.
+Consider the following procedure when placing Warthog in long-term storage:
+
+- Fully charge Warthog, turn it off and put it into storage.
+ Once a week, connect power to the charger and allow the charger to top up the battery for an hour or so.
+
+Please contact Clearpath Robotics for additional information about Warthog's batteries.
+
+---
+
+## Tracks Upgrade
+
+If your unit came equipped with the tracks upgrade, please keep the following considerations in mind:
+
+- The tracks drive units pull considerably more current to operate.
+ It is advised to operate a Warthog with tracks at reduced speeds, either through ROS commands or by reducing the speed scale when operating with the Futaba controller.
+- Due to the increased drive current, expect lower battery life than a wheeled Warthog.
+ It is recommend to drive at reduced speeds to increase battery life.
+- It is possible to trigger an over current error in the motor controller by increasing speed drastically shortly after resetting a stop condition.
+ The system's body lights will seem as if the unit is ready to drive, however it will not respond to drive commands.
+ To clear this state, simply cycle another stop condition, and ramp up speeds slower.
+
+---
+
+## Software Maintenance {#software_maintenance}
+
+### Getting New Packages
+
+
+
+### MCU Firmware Update
+
+:::caution
+
+Accessing Warthog's MCU requires access to several hard-to-get-to parts of the robot. Unless absolutely
+necessary, we do not recommend re-flashing the robot's MCU firmware.
+
+:::
+
+You need to use an external computer to update Warthog's MCU firmware. You cannot use Warthog's Onboard Computer, as installing the
+firmware requires power-cycling the MCU. Warthog's MCU controls the power supply to the Onboard Computer. These instructions
+assume the external computer is running some flavour of Linux with access to Clearpath's ROS packages.
+
+
+
+---
+
+## Support
+
+
diff --git a/docs/robots/outdoor_robots/warthog/troubleshooting_warthog.mdx b/docs/robots/outdoor_robots/warthog/troubleshooting_warthog.mdx
new file mode 100644
index 000000000..7a04f0c89
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/troubleshooting_warthog.mdx
@@ -0,0 +1,54 @@
+---
+title: Warthog Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 6
+---
+
+import ComponentIntroductionWarthog from "/components/introduction_warthog.mdx";
+import ComponentSupportIntroduction from "/components/support_introduction.mdx";
+import Support from "/components/support.mdx";
+
+
+
+
+
+---
+
+## Networking
+
+### Not getting Wi-Fi internet connection
+
+Refer to the [Networking page](../../../ros/networking/overview.mdx).
+
+### Cannot connect to the robot's computer over a network cable
+
+Reter to the [Networking page](../../../ros/networking/overview.mdx).
+
+---
+
+## Computer
+
+### The computer does not automatically start
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+### The computer keeps reverting to old BIOS settings
+
+Refer to the [Mini ITX troubleshooting page](../../accessories/computers/mini_itx.mdx).
+
+---
+
+## ROS
+
+### ROS package is not starting
+
+Verify the upstart logs, `/var/log/upstart/husky_core.log`, to see if there are any error during upstart.
+
+### Sensors are not turning on
+
+1. Check that the sensor's User Power connector has the correct voltage.
+2. If the voltage is correct, then review the [Troubleshooting section for the related sensor](../../accessories/sensors/sensors.mdx).
+
+## If the Issue Persists
+
+
diff --git a/docs/robots/outdoor_robots/warthog/tutorials_warthog.mdx b/docs/robots/outdoor_robots/warthog/tutorials_warthog.mdx
new file mode 100644
index 000000000..962d9dd6a
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/tutorials_warthog.mdx
@@ -0,0 +1,29 @@
+---
+title: Warthog Tutorials
+sidebar_label: Tutorials
+sidebar_position: 4
+---
+
+import ComponentIntroductionWarthog from "/components/introduction_warthog.mdx";
+import ComponentTutorialLinks from "../../../components/_tutorials_link.mdx";
+import Support from "/components/support.mdx";
+
+
+
+## Warthog Overview
+
+### Introduction
+
+Clearpath Robotics Warthog is a rugged, all-terrain unmanned ground vehicle.
+
+The Warthog is currently only supported in [ROS 1](/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/tutorials_warthog.mdx).
+
+For more information or to receive a quote, please [visit us online](http://clearpathrobotics.com/warthog).
+
+
+
+---
+
+## Support {#support}
+
+
diff --git a/docs/robots/outdoor_robots/warthog/user_manual_warthog.mdx b/docs/robots/outdoor_robots/warthog/user_manual_warthog.mdx
new file mode 100644
index 000000000..69583aada
--- /dev/null
+++ b/docs/robots/outdoor_robots/warthog/user_manual_warthog.mdx
@@ -0,0 +1,473 @@
+---
+title: Warthog User Manual
+sidebar_label: User Manual
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ComponentIntroductionWarthog from "/components/introduction_warthog.mdx";
+import ComponentUsingRos from "/components/using_ros.mdx";
+import Support from "/components/support.mdx";
+import ComponentCommonSafeWorkProcedures from "/components/common_safe_work_procedures.mdx";
+
+
+
+## Introduction
+
+Clearpath Robotics Warthog is a rugged, all-terrain unmanned ground vehicle capable of brief periods of locomotion
+in water. Warthog fully supports the Robot Operating System (ROS) and can be equipped with a variety of payloads,
+including sensors and manipulators, to accommodate a wide range of robotics applications in mining, agriculture
+and environmental monitoring.
+
+### Shipment Contents
+
+Your Warthog shipment contains the following:
+
+- Warthog UGV
+ - Onboard computer
+ - User Breakout Panel with power, Ethernet, Serial (RS232) and USB connectivity
+ - 48 V Lead-Acid Battery Pack or 48 V LiFEPO4 Battery Pack
+- One battery charger
+- One Futaba remote control
+- One Warthog quick start guide
+- One Wireless Stop remote
+
+If you purchased standard payload modules or custom integration services with Warthog, then additional equipment
+will be included per your specific configuration, plus further documentation as required.
+
+### Hardware Overview
+
+#### System Architecture
+
+Warthog is built around an onboard computer running Ubuntu (Intel-based computer or Jetson developer kit), paired with a
+32-bit microcontroller MCU. The MCU handles IO, system and battery monitoring, and provides an interface to the CAN-controlled
+motor drivers. The communication channel between the MCU and computer is an Ethernet connection.
+
+
+
+
+ System Architecture
+
+
+
+#### System Features
+
+The Warthog is shown below and includes:
+
+- Battery charger access
+- Bilge pumps
+- User breakouts
+- Payload integration area
+- Four Stop buttons (one on each corner)
+- Four body lights (one on each corner)
+
+
+
+
+
+
+ Warthog hardware overview
+
+
+
+#### Battery Charger Access
+
+Please review [this PDF](/assets/pdf/clearpath_robotics_016519-TDS1.pdf) for information about the provided charger.
+
+#### Bilge Pumps
+
+The Warthog has two bilge pumps, with one situated in each of the drive units underneath the motor.
+The bilge pumps are used to remove water from the main chassis and drive units during operation in water.
+At initial startup, an audible sound can be heard from the bilge pumps being initiated.
+These pumps are an automatic pumping system that check for water levels inside the drive units.
+The pumps automatically come on every two minutes and check for water levels.
+If the water level inside the drive unit exceeds a predetermined level, the pumps will remain on, otherwise they will shut off.
+During prolonged use in water, some water may appear in the drive unit.
+This is normal and acceptable.
+This outlet leads from the pump to the exterior of the Warthog.
+It is used to remove excess water from the chassis and drive units.
+No obstructions should be placed in front of or around this area.
+Obstruction of water flow may result in damage to the internal electrical components and loss of function in the Warthog.
+
+#### User Breakouts
+
+The User Breakout Panel provides access to the user power panel, as well as USB, serial, and ethernet ports.
+The power panel can be used to power your payloads.
+The USB 3.0 and Ethernet ports are connected directly to the onboard computer.
+To connect a device to the onboard network, it's suggested to give it a static IP in the _192.168.131.xxx_ subnet, avoiding IPs in use by the following pre-existing devices:
+
+| IP address | Description |
+| :-----------: | :-------------------------------------------------- |
+| 192.168.131.1 | Onboard Computer (all ports, br0 network interface) |
+| 192.168.131.2 | Ethernet-connected MCU |
+
+Typically addresses numbered 192.168.131.100 and above will not collide with any of Warthog's payloads.
+Please see [Electrical Integration](integration_warthog/integration_warthog.mdx#warthog-electrical-integration) for more information.
+
+#### Payload Integration Area
+
+All payloads should be mounted to the central chassis when traversing through water to prevent rolling.
+The primary payload of the unit should be placed on the central chassis.
+If necessary loading can be placed on the drive units however payloads should not exceed 23 kg (50 lbs) on each drive unit.
+
+For more information and guidance on mounting payload structures on top of Warthog, please refer to subsection
+[Mechanical Mounting](integration_warthog/integration_warthog.mdx#warthog-mechanical-mounting).
+
+#### Body Lights
+
+Warthog includes four RGB body lights, one on each corner of the chassis. These lights
+express system status according to the table below, but in the absence of one of the low-level conditions, they can
+be commanded from ROS to display indications from autonomy or other higher-level software.
+See http://wiki.ros.org/warthog_base for information on commanding the body lights.
+
+| Front Lights | Rear Lights | System State |
+| :-------------- | :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Solid red | Solid red | The MCU is not in contact with the computer. That is, the `rosserial` connection is not active. This condition will be seen briefly on startup while Warthog's computer is booting up. If it persists, or is seen after initialization, either the base node on the computer has crashed, the network switch has failed, or a serious MCU error has occurred. If you suspect one of these conditions, please contact support. |
+| Flashing red | Flashing red | Stop mode is engaged. To disengage, twist the mushroom buttons on the Warthog and on the Wireless Stop remote to ensure that they are unlatched. See also [Using the Wireless Stop Remote](#using-the-wireless-stop-remote). |
+| Flashing orange | Flashing orange | Motor drivers not yet ready to drive. The motors have a brief initialization sequence which must complete after a stop condition clears before they are ready to drive. If this condition persists, please contact our support team. |
+| Pulsing orange | Pulsing orange | Battery is low. Connect Warthog to the charger. |
+| Solid white | Solid red | Normal operation; Warthog is ready to drive. This status may be overridden by publishing your own light patterns to the `/cmd_lights` ROS topic. |
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855. When commanded with a positive translational
+velocity (forward), wheels travel in the positive X-direction. The direction of the axes differs from those used for roll, pitch,
+and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+### System Specifications
+
+| Specification | Value |
+| :------------------------------ | :----------------------------------------------------------------------------------------- |
+| External Dimensions (L x W x H) | 1.52 X 1.38 X 0.83 metres (4.9' X 4.5' X 2.72') |
+| Base Weight | 280 kg (551 lbs) |
+| Ground Clearance | 254 mm (10 in) |
+| Max Payload | 272 kg (600 lbs) |
+| Max Incline | 35 - 45° |
+| Max Speed | 18 km/h (11 mph) |
+| Suspension | Geometric Passive Articulation |
+| Drive Configuration | 4 X 4 Skid Steer |
+| Operating Environment | Outdoor |
+| Traction | Ø610 mm (24") Argo Turf tire (default) or 300 mm (12") wide Quad Track System (optional) |
+| Battery Chemistry | AGM sealed lead-acid (LiFEPO4 optional) |
+| Capacity | 105 Ah at 48 V, expandable to 118 Ah at 51.2V with LiFEPO4 option |
+| Nominal Run Time | Lead-acid: 2.5 hrs, LiFEPO4: 6 hrs |
+| Charge Time | 4 Hours approx |
+| User Power | 12 V, 24 V and 48 V Fused at 10 A |
+| Control Modes | Remote control, computer controlled velocity commands, indoor/outdoor autonomy packages |
+| Feedback Battery | Voltage, motor currents, wheel odometry, control system status, temperature, safety status |
+| Communication | Ethernet, USB, Remote Control, Wi-Fi |
+| Drivers | Packaged with ROS Noetic (includes RViz, Gazebo support), Matlab API available |
+
+
+
+
+ Warthog dimensions
+
+
+
+---
+
+## Getting Started
+
+You are ready to go! This section details how to get Warthog into action.
+To begin, place Warthog "up on blocks", making sure that the wheels are clear of the ground.
+
+For most Warthog setups, there will be an Onboard Computer which is directly connected to the Warthog and an Offboard Computer which is used to control Husky and gather data.
+These two computers must be set up to communicate with each other.
+
+### Onboard Computer Setup
+
+Warthog ships with an Onboard Computer from Clearpath Robotics, which is already installed, connected, and powered.
+If you need to reinstall the software on it, refer to the [Warthog Tutorials](tutorials_warthog.mdx).
+
+### Powering Up
+
+To power on your Warthog, twist the red power button on the back of Warthog. Once the body lights are flashing red,
+twist (to reset) all four Stop buttons (if necessary), and press go on the Wireless Stop remote (next section).
+In a moment, Warthog should go to solid red lights in back, and solid white in front.
+This indicates that ROS is up on the computer and has established communications with the MCU.
+
+### Using the Wireless Stop Remote {#using-the-wireless-stop-remote}
+
+Included with the Warthog is a Wireless Stop remote. If for any reason the robot must be halted immediately, press the red STOP button.
+This will immediately cut power to the robot's motors.
+
+
+
+
+ Warthog's Wireless Stop Remote
+
+
+
+It's capable of engaging a stop remotely.
+The system is designed to enter a stopped state when the remote is not communicating or loses communication with the base.
+The Wireless Stop remote operates as follows:
+
+1. Pull the red STOP button outwards to disengage it from a stop condition.
+2. Press and hold the green START button on the right side of the unit until the battery LED indicator above the buttons turns green.
+ If the battery light is red, this means the STOP button is still engaged.
+3. Press the button labelled RELEASE within three seconds followed by the START button again.
+4. The battery LED should be blinking green quickly, this indicates the remote is paired with the receiver.
+ To disengage the stop, press START once again.
+
+The battery LED should now be blinking slower, this indicates the remote stop has been disengaged.
+The corner body lights of the Warthog will change from blinking red to solid red at the rear and white at the front assuming
+all other safety stop sources have been disengaged.
+The Warthog is now ready to drive.
+
+:::note
+
+If you're not seeing any change in behaviour, please contact our support team.
+
+:::
+
+### Using the Stop buttons
+
+Warthog has four Stop buttons located on the four corners of the robot. Pressing any of
+these buttons will cut power to the motors, just like the STOP button on the Wireless Stop remote.
+To disengage the stop, simply twist the button in the direction indicated by the arrows.
+
+Whenever you need to perform maintenance on Warthog, we recommend engaging the stop if the
+robot cannot be fully powered down.
+
+### Drivetrain
+
+The Warthog has the ability to be put into neutral which is controlled be the four levers (two per side) in the
+rockers.
+
+
+
+
+ Drivetrain lever
+
+
+
+Use the bolts to restrict the lever from moving as down when the drivetrain is in neutral.
+The groove for the neutral position is marked with white and the bolt is also marked.
+This is shown below.
+
+
+
+
+ Drivetrain in neutral
+
+
+
+Pull the handle on the lever to move it into gear which can be seen below.
+Ensure the lever is in the green groove.
+If the lever is difficult to move, rock the Warthog back and forth.
+Do not try to force the lever to move.
+
+
+
+
+ Drivetrain in gear
+
+
+
+### Using the Futaba Controller {#controller}
+
+The long range remote control (RC) Futaba radio transmitter can be used to teleoperate the Warthog.
+To begin, slide the power switch to the ON position which is labelled in the figure below.
+
+:::caution
+
+The speed adjustment knob should be turned initially all the way to the left while familiarizing yourself with the
+transmitter and slowly increasing it to get it moving.
+
+:::
+
+The position of the speed adjustment scale is shown in the figure as _CH4_.
+The transmitter needs to be enabled which is done using the _Enable Switch_.
+The _Enable Switch_ is a two position spring loaded switch.
+To enable the RC teleoperation, the switch needs to be held down.
+If released, the switch returns to the up position to disable the robot.
+The left joystick is used for the forward and reverse motion of the robot and the right joystick is used for turning.
+
+
+
+
+ Futaba radio transmitter
+
+
+
+
+
+
+ Futaba radio transmitter's screen
+
+
+
+:::note
+
+If the Clearpath Robotics Outdoor Navigation software is installed on the Warthog, the Futaba remote controller (RC) must be turned OFF for autonomous missions to be properly executed by the navigation software.
+The Futaba RC will always publish messages to the `/rc_teleop/cmd_vel` topic when it is ON, and since it has higher priority than the navigation's `/cmd_vel`, the Warthog will not move if autonomous missions are sent and the RC is still ON.
+
+:::
+
+### Network Configuration
+
+To get Warthog connected to your local Wi-Fi network, you must first access the Onboard Computer using a wired connection to the robot.
+Locate the User Breakout Panel on the rear of the chassis and connect to an Ethernet port with a standard
+Ethernet cable. See the [Warthog Tutorials](tutorials_warthog.mdx) for details
+on completing the Wi-Fi setup.
+
+### Using ROS
+
+
+
+---
+
+## Safety Considerations {#safety}
+
+Clearpath Robotics is committed to high standards of safety.
+Warthog contains several features to protect the safety of users and the integrity of the robot.
+
+:::danger
+
+Warthog is a powerful, heavy, fast moving robotic platform.
+Please read the following safety information carefully.
+
+:::
+
+### General Warnings
+
+For the safety of yourself and others, always conduct initial experiments and software development with the motors not engaged.
+Whenever the robot is not being operated and the motors are engaged, keep it in a stop state.
+Do not ride on the vehicle, it can accelerate and brake quickly.
+
+When starting out, favour slower wheel speeds.
+Warthog's control loops can accurately maintain velocities as low as 0.1 m/s.
+Operating at such speeds will give you more time to react if things don't go quite as you expect.
+
+When enabling the system using the GO button on the wireless remote, be sure to stand well back from the Warthog.
+User code running on the Warthog may still be trying to command the motors, and this can result in sudden and unexpected movement of the vehicle.
+Be prepared to stop the system again using the wireless remote.
+
+### Maneuverability in Water
+
+Before entering the water it is important to ensure that:
+
+- Bilge pumps are functioning properly
+- The side panels and top cover are properly fastened down
+- All access panels are fastened down
+
+### Pinch Points {#warthog-pinch-points}
+
+When operating the Warthog it is important to maintain a safe distance away from the unit.
+The suspension has the ability to pivot.
+Do not place fingers anywhere along the suspension link as it can result in injury.
+
+
+
+
+ Warthog pinch point
+
+
+
+### Stop buttons
+
+The Stop system on the Warthog has two major components: The hardwired Stop switches and the Wireless
+Stop remote.
+
+#### Hardwired Stop
+
+Pressing down one of the 4 red mushroom Stop buttons around the Warthog will disable power to the motor controller SEVCON devices (Key switch input on PIN 1).
+This disables the large contactors and also enables the brakes (passive, spring activated when not powered).
+The status indicator lights around the Warthog will flash red.
+To reset a Stop button, the top of the button should be twisted until the button pops out again.
+The GO button on Wireless remote must then pressed.
+The Warthog is fully enabled once a relay click is heard, and the front lights change to white.
+
+#### Wireless Stop Remote
+
+To operate the Warthog, the Wireless Stop remote also has to be powered on (by holding the Power button for at least 1 second).
+The remote STOP button toggles the stop status.
+It must be pressed once to enable stop, and pressed again to return to a stop reset ready state.
+The GO button on the remote will then reset the stop condition.
+Always ensure the STOP button is accessible at all times.
+Avoid mounting payloads that extend over the rear of Warthog and would occlude the Stop buttons.
+
+### Electrical System
+
+The largest electrical safety consideration with the Warthog system is the VBAT connection.
+As it is pulled straight from the batteries, it may have a voltage of 48 V (depleted) to 62 V (Charging) and can be used to power large external devices.
+This voltage can cause electrical shock if directly contacted, and is fused internally with an inline fuse at 10 A.
+In general, take care to connect or disconnect devices preferably only when the entire system is powered off via the external switch on the rear (main power switch).
+Take note that triggering a stop condition only disables voltage to the motor controller SEVCON drivers and motors, not the rest of the system which includes the connectors.
+The labelled status LEDs on the user panels indicate status of the system voltages.
+If a LED is not lit, then it's most likely that a system fuse has blown.
+Contacting Clearpath support is the best option.
+To ensure safety, please also observe the following precautions:
+
+- Do not tamper with the battery terminals or wiring.
+- Consult Clearpath Robotics support if you need to service the battery pack.
+- Do not lay tools or other objects on top of the battery.
+- Do not move the robot while charging the battery.
+- Charge the battery only with the charger provided by Clearpath Robotics.
+- Please dispose of the batteries properly, or return the batteries to Clearpath Robotics to do so.
+
+### Lifting and Transport
+
+For the safety of users and to maximize the lifetime of Warthog, please observe the following when manually transporting the robot:
+
+- Ensure that Warthog's stop mode is engaged when transporting short distances and powered off when transporting longer distances.
+- Do not push the robot at more than 0.5 m/s (1.6 ft/s) or damage to the motor controls may occur.
+
+### Performance Considerations
+
+Included in Warthog are native software checks and limits to protect the robot.
+However, it is recommended to monitor the system's status during usage with the `/status` and `/diagnostics` topics.
+These topics provide useful information regarding voltages, currents, temperatures and general health of the system.
+
+### Recommended Safe Work Procedures
+
+#### Common Safe Work Procedures
+
+
+
+#### Warthog-Specific Safe Work Procedures
+
+- Keep hands and fingers away from the suspension linkage components at the rear of the robot.
+- Never approach the robot while it is operating in water.
+- When working on or around the robot always disconnect the motors using the drivetrain levers as described in the user manual.
+- Never disconnect the robot motors using drivetrain levers when on a slope.
+- Do not attempt to move or operate the robot while charging the batteries.
+
+---
+
+## Support
+
+
diff --git a/docs/robots/robots.mdx b/docs/robots/robots.mdx
new file mode 100644
index 000000000..58c32352a
--- /dev/null
+++ b/docs/robots/robots.mdx
@@ -0,0 +1,47 @@
+---
+title: Robots Overview
+sidebar_label: Robots Overview
+sidebar_position: 1
+---
+
+
+
+
+
+We make base robot platforms, build custom integrations, and design bespoke robots to meet our customers' applications.
+
+We are committed to the [Robot Operating System (ROS)](https://ros.org/) and the community of researchers and users that support it.
+Each robot that Clearpath deploys is designed to be used with this open source platform.
+The extensibility of ROS has also allowed Clearpath to use it to develop the proprietary autonomy software for indoor and outdoor use.
+
+:::tip we suggest you:
+
+1. Review the documentation for our robot platforms, sensors, add-ons, and autonomy software.
+2. Try some of our tutorials. Some of these tutorials use a simulated robot, so you can try developing with ROS before purchasing hardware.
+3. Review some of our [GitHub](https://github.com/clearpathrobotics) repositories.
+4. Discuss your application with our Sales team at \, whether you already have a robot or not.
+
+:::
+
+:::info links to our robot pages
+
+- [Boxer](indoor_robots/boxer/user_manual_boxer.mdx)
+- [Dingo](indoor_robots/dingo/user_manual_dingo.mdx)
+- [Husky](outdoor_robots/husky)
+- [Husky Observer](solutions/husky_observer/husky_observer.mdx)
+- [Jackal](outdoor_robots/jackal/user_manual_jackal.mdx)
+- [Ridgeback](indoor_robots/ridgeback/user_manual_ridgeback.mdx)
+- [TurtleBot 4](learning_platforms/turtlebot4.mdx)
+- [Warthog](outdoor_robots/warthog/user_manual_warthog.mdx)
+
+:::
diff --git a/docs/robots/solutions/_category_.json b/docs/robots/solutions/_category_.json
new file mode 100644
index 000000000..73361e5e3
--- /dev/null
+++ b/docs/robots/solutions/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Solutions",
+ "position": 5
+}
diff --git a/docs/robots/solutions/husky_observer/husky_observer.mdx b/docs/robots/solutions/husky_observer/husky_observer.mdx
new file mode 100644
index 000000000..a9f26f66e
--- /dev/null
+++ b/docs/robots/solutions/husky_observer/husky_observer.mdx
@@ -0,0 +1,14 @@
+---
+title: Husky Observer
+sidebar_label: Husky Observer
+sidebar_position: 1
+---
+
+:::note
+
+Husky Observer is currently available in ROS 1 Noetic only. Use the link below
+to access the User Manual.
+
+[Link to Husky Observer User Manual](/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/user_manual_husky_observer.mdx)
+
+:::
diff --git a/docs/ros/api/_category_.json b/docs/ros/api/_category_.json
new file mode 100644
index 000000000..a4b6671f1
--- /dev/null
+++ b/docs/ros/api/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "API",
+ "position": 3
+}
diff --git a/docs/ros/api/lighting.mdx b/docs/ros/api/lighting.mdx
new file mode 100644
index 000000000..bbf6a5b59
--- /dev/null
+++ b/docs/ros/api/lighting.mdx
@@ -0,0 +1,197 @@
+---
+title: Lighting
+sidebar_label: Lighting
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+Corner lighting is unified for platforms that support it (D100, D150, R100, W200). Lighting is controlled by the [lighting node](https://github.com/clearpathrobotics/clearpath_common/tree/humble/clearpath_platform/src/lighting) which defines multiple lighting states.
+The platforms lighting state is determined based on data from multiple platform status topics. Lighting states are given a priority, such that the most important state (lowest priority value) is displayed first.
+
+The lighting node will publish the current lighting command directly to the MCU. It also subscribes to user lighting commands, and will instead publish those user commands if appropriate.
+
+
+## Lighting States
+
+
+
+
+
Lighting State
+
Lighting Pattern
+
Priority
+
User commands allowed
+
Platform
+
+
+
+
+
Battery Fault
+
+
+
+
+
+
0
+
No
+
D100, D150, R100, W200
+
+
+
Shore Power Fault
+
+
+
+
+
+
1
+
No
+
D100, D150
+
+
+
Shore Power and Charged
+
+
+
+
+
+
2
+
Yes
+
D100, D150
+
+
+
Shore Power and Charging
+
+
+
+
+
+
3
+
Yes
+
D150
+
+
+
Shore Power
+
+
+
+
+
+
4
+
Yes
+
D100, D150
+
+
+
Charged
+
+
+
+
+
+
5
+
Yes
+
D100, D150, R100, W200
+
+
+
Charging
+
+
+
+
+
+
6
+
Yes
+
D150, R100
+
+
+
Stopped
+
+
+
+
+
+
7
+
No
+
D100, D150, R100, W200
+
+
+
Needs Reset
+
+
+
+
+
+
8
+
No
+
R100
+
+
+
Low Battery
+
+
+
+
+
+
9
+
No
+
D100, D150, R100, W200
+
+
+
Driving
+
+
+
+
+
+
10
+
Yes
+
D100, D150, R100, W200
+
+
+
Idle
+
+
+
+
+
+
11
+
Yes
+
D100, D150, R100, W200
+
+
+
diff --git a/docs/ros/api/mcu_api.mdx b/docs/ros/api/mcu_api.mdx
new file mode 100644
index 000000000..849e0ac34
--- /dev/null
+++ b/docs/ros/api/mcu_api.mdx
@@ -0,0 +1,27 @@
+---
+title: ROS 2 MCU API
+sidebar_label: MCU API
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+## MCU topics
+
+| Topic | Message type | Publisher | Description | QoS |
+| :------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | :----------------------------------------------------- | :---------------------------------------------- |
+| platform/emergency_stop | [std_msgs/Bool](https://github.com/ros2/common_interfaces/blob/humble/std_msgs/msg/Bool.msg) | MCU node | State of platform emergency stop | [Sensor Data](overview.mdx#sensor-data) |
+| platform/mcu/_cmd_lights | [clearpath_platform_msgs/Lights](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Lights.msg) | Lighting command | Hidden topic used to send lighting commands to the MCU | [Sensor Data](overview.mdx#sensor-data) |
+| platform/mcu/status | [clearpath_platform_msgs/Status](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Status.msg) | MCU node | MCU status | [Sensor Data](overview.mdx#sensor-data) |
+| platform/mcu/status/power | [clearpath_platform_msgs/Power](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Power.msg) | MCU node | Robot Power status | [Sensor Data](overview.mdx#sensor-data) |
+| platform/mcu/status/stop | [clearpath_platform_msgs/StopStatus](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/StopStatus.msg) | MCU node | Stop loop status | [Sensor Data](overview.mdx#sensor-data) |
+| platform/motors/cmd_drive | [clearpath_platform_msgs/Drive](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Drive.msg) | Control node | Command velocities to individual wheels | [Sensor Data](overview.mdx#sensor-data) |
+| platform/motors/feedback | [clearpath_platform_msgs/DriveFeedback](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/DriveFeedback.msg) | MCU node | Feedback from motor drive unit | [Sensor Data](overview.mdx#sensor-data) |
+| platform/wifi_connected | [std_msgs/Bool](https://github.com/ros2/common_interfaces/blob/humble/std_msgs/msg/Bool.msg) | Wireless Watcher node | Wi-Fi connected status | [Sensor Data](overview.mdx#sensor-data) |
+| /rosout | [rcl_interfaces/Log](https://github.com/ros2/rcl_interfaces/blob/humble/rcl_interfaces/msg/Log.msg) | MCU node | System Logs | [Transient Local](overview.mdx#transient-local) |
+
+## MCU services
+
+| Service | Service type | Server | Description | QoS |
+| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | :------- | :------------------------------------ | :------------- |
+| platform/mcu/configure | [clearpath_platform_msgs/ConfigureMcu](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/srv/ConfigureMcu.srv) | MCU node | Configure MCU domain ID and namespace | System default |
diff --git a/docs/ros/api/overview.mdx b/docs/ros/api/overview.mdx
new file mode 100644
index 000000000..5f1ee68e4
--- /dev/null
+++ b/docs/ros/api/overview.mdx
@@ -0,0 +1,98 @@
+---
+title: ROS 2 Robot API
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+The ROS 2 API is a standard naming scheme for ROS 2 topics and services. Every supported Clearpath
+robot uses this API, making it easy to use the robots interchangeably.
+
+## QoS Profiles {#qos-profiles}
+
+Topics and services in ROS 2 use Quality of Service (QoS) profiles to change communication policies. The QoS profile
+of a topic or service has several policies such as history, depth, reliability, durability, and more. For more details on
+QoS settings, visit the [ROS 2 documentation](https://docs.ros.org/en/humble/Concepts/About-Quality-of-Service-Settings.html).
+
+For Clearpath platforms, the main policies that may change between different topics and services are reliability and durability. For reliability
+there are two options: _Best Effort_, and _Reliable_. A _Best Effort_ reliability suggests that an attempt will be made to publish
+the data, but if the network is not robust then the data may be lost. On the other hand, _Reliable_ guarantees that the data will be received.
+This may require that the data be sent multiple times.
+
+The durability of a QoS profile can be either _Transient Local_ or _Volatile_. _Transient Local_ means that data for published messages will
+be stored by the publisher even after it has been published. A new subscriber will receive the data even if a lot of time has passed since it was originally published.
+This durability is typically used for data that only needs to be published once, such as the robot description. The other durability policy is _Volatile_ which does not
+store old messages. The messages are published and only active subscribers will receive the data. New subscribers will have to wait for the next message to be published.
+Most topics will use a _Volatile_ durability policy.
+
+It is important to check for [QoS compatibility](https://docs.ros.org/en/humble/Concepts/Intermediate/About-Quality-of-Service-Settings.html#qos-compatibilities) when interacting with ROS 2.
+Mixing of QoS policies when publishing or subscribing to topics can lead to incompatibility. For example, subscribing to a Best Effort publisher with a Reliable subscriber
+is not compatible and will result in no data being received on the subscriber. The easiest way to check the QoS profile of a topic is to use the ROS 2 command line interface.
+
+```
+ros2 topic info /topic_name -v
+```
+
+### Common QoS profiles {#common-qos-profiles}
+
+The following are some common QoS profiles used by Clearpath platforms.
+
+#### System Default
+
+- **History**: _Keep Last_
+- **Depth**: _10_
+- **Reliability**: _Reliable_
+- **Durability**: _Volatile_
+- **Deadline**: _System Default_
+- **Lifespan**: _System Default_
+- **Liveliness**: _Automatic_
+- **Lease Duration**: _System Default_
+
+The _System Default_ QoS profile is the most common profile used by most topics.
+
+#### Sensor Data
+
+- **History**: _Keep Last_
+- **Depth**: _5_
+- **Reliability**: _Best Effort_
+- **Durability**: _Volatile_
+- **Deadline**: _System Default_
+- **Lifespan**: _System Default_
+- **Liveliness**: _Automatic_
+- **Lease Duration**: _System Default_
+
+The _Sensor Data_ QoS Profile uses a _Best Effort_ reliability to send the latest data
+as soon as possible, without bothering to resend data that was not received. This is mostly used
+by the MCU and sensor drivers.
+
+:::note
+
+Not all sensor drivers use this QoS profile. Always check the QoS profile before trying to subscribe to the topic.
+
+:::
+
+#### Transient Local
+
+- **History**: _Keep Last_
+- **Depth**: _10_
+- **Reliability**: _Reliable_
+- **Durability**: _Transient Local_
+- **Deadline**: _System Default_
+- **Lifespan**: _System Default_
+- **Liveliness**: _Automatic_
+- **Lease Duration**: _System Default_
+
+The _Transient Local_ QoS Profile offers a _Transient Local_ durability, and is typically used by topics that only
+want to send messages once. For Clearpath platforms, this includes the robot description topic and the `/rosout` topic
+which offers system logs.
+
+## Namespacing
+
+Namespacing is the method of adding a prefix to a robot's nodes and topics; this helps differentiate them from another robot that
+may be on the same network. For example, every robot will have a `cmd_vel` topic for commanding velocity. If both robots
+used the same topic, then they would both drive when a message is published to that topic. By namespacing, we can remap the topic
+to `robot1/cmd_vel` and `robot2/cmd_vel` for each respective robot.
+
+By default, the namespace of the robot will be obtained from the serial number of the robot. If your serial number is `cpr-a200-0001`, then your namespace
+will be `a200_0001`. This can be overwritten in the [robot.yaml](../config/yaml/overview.mdx) file.
diff --git a/docs/ros/api/platform_api.mdx b/docs/ros/api/platform_api.mdx
new file mode 100644
index 000000000..bf539dd4f
--- /dev/null
+++ b/docs/ros/api/platform_api.mdx
@@ -0,0 +1,33 @@
+---
+title: ROS 2 Platform API
+sidebar_label: Platform API
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+## Platform topics
+
+| Topic | Message type | Publisher | Description | QoS |
+| :---------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | :-------------------------------------------- | :---------------------------------------------- |
+| cmd_vel | [geometry_msgs/Twist](https://github.com/ros2/common_interfaces/blob/humble/geometry_msgs/msg/Twist.msg) | User | Commands the robot to drive at a velocity | [System Default](overview.mdx#system-default) |
+| diagnostics | [diagnostics_msgs/DiagnosticArray](https://github.com/ros2/common_interfaces/blob/humble/diagnostic_msgs/msg/DiagnosticArray.msg) | Various nodes | Diagnostic messages reported by various nodes | [System Default](overview.mdx#system-default) |
+| joy_teleop/cmd_vel | [geometry_msgs/Twist](https://github.com/ros2/common_interfaces/blob/humble/geometry_msgs/msg/Twist.msg) | Joy node | Velocity commands from joystick inputs | [System Default](overview.mdx#system-default) |
+| joy_teleop/joy | [sensor_msgs/Joy](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Joy.msg) | Joy node | Joystick input states | [System Default](overview.mdx#system-default) |
+| platform/bms/state | [sensor_msgs/BatteryState](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/BatteryState.msg) | Battery node | System battery state | [Sensor Data](overview.mdx#sensor-data) |
+| platform/cmd_lights | [clearpath_platform_msgs/Lights](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Lights.msg) | User | User lighting command request | [System Default](overview.mdx#system-default) |
+| platform/cmd_vel_unstamped | [geometry_msgs/Twist](https://github.com/ros2/common_interfaces/blob/humble/geometry_msgs/msg/Twist.msg) | Twist Mux node | Resulting velocity commands from twist mux | [System Default](overview.mdx#system-default) |
+| platform/dynamic_joint_states | [control_msgs/DynamicJointState](https://github.com/ros-controls/control_msgs/blob/humble/control_msgs/msg/DynamicJointState.msg) | Control node | Platform dynamic joint state | [System Default](overview.mdx#system-default) |
+| platform/emergency_stop | [std_msgs/Bool](https://github.com/ros2/common_interfaces/blob/humble/std_msgs/msg/Bool.msg) | MCU node | State of platform emergency stop | [Sensor Data](overview.mdx#sensor-data) |
+| platform/joint_states | [sensor_msgs/JointState](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/JointState.msg) | Control node | Platform joint state | [System Default](overview.mdx#system-default) |
+| platform/motors/cmd_drive | [clearpath_platform_msgs/Drive](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/Drive.msg) | Control node | Command velocities to individual wheels | [Sensor Data](overview.mdx#sensor-data) |
+| platform/motors/feedback | [clearpath_platform_msgs/DriveFeedback](https://github.com/clearpathrobotics/clearpath_msgs/blob/main/clearpath_platform_msgs/msg/DriveFeedback.msg) | MCU node | Feedback from motor drive unit | [Sensor Data](overview.mdx#sensor-data) |
+| platform/odom | [nav_msgs/Odometry](https://github.com/ros2/common_interfaces/blob/humble/nav_msgs/msg/Odometry.msg) | Control node | Platform wheel odometry | [System Default](overview.mdx#system-default) |
+| platform/odom/filtered | [nav_msgs/Odometry](https://github.com/ros2/common_interfaces/blob/humble/nav_msgs/msg/Odometry.msg) | EKF node | Platform wheel odometry fused with IMU data | [System Default](overview.mdx#system-default) |
+| platform/wifi_connected | [std_msgs/Bool](https://github.com/ros2/common_interfaces/blob/humble/std_msgs/msg/Bool.msg) | Wireless Watcher node | Wi-Fi connected status | [System Default](overview.mdx#system-default) |
+| platform/wifi_status | [wireless_msgs/Connection](https://github.com/clearpathrobotics/wireless/blob/foxy-devel/wireless_msgs/msg/Connection.msg) | Wireless Watcher node | Wi-Fi signal status | [System Default](overview.mdx#system-default) |
+| robot_description | [std_msgs/String](https://github.com/ros2/common_interfaces/blob/humble/std_msgs/msg/String.msg) | Robot State Publisher | Robot description | [Transient Local](overview.mdx#transient-local) |
+| tf | [tf2_msgs/TFMessage](https://github.com/ros2/geometry2/blob/humble/tf2_msgs/msg/TFMessage.msg) | Various nodes | Link transforms | [System Default](overview.mdx#system-default) |
+| tf_static | [tf2_msgs/TFMessage](https://github.com/ros2/geometry2/blob/humble/tf2_msgs/msg/TFMessage.msg) | Various nodes | Static link transforms | [Transient Local](overview.mdx#transient-local) |
+| twist_marker_server/cmd_vel | [geometry_msgs/Twist](https://github.com/ros2/common_interfaces/blob/humble/geometry_msgs/msg/Twist.msg) | Twist Marker Server | Velocity commands from twist marker | [System Default](overview.mdx#system-default) |
+| /rosout | [rcl_interfaces/Log](https://github.com/ros2/rcl_interfaces/blob/humble/rcl_interfaces/msg/Log.msg) | Various nodes | System Logs | [Transient Local](overview.mdx#transient-local) |
diff --git a/docs/ros/api/sensors_api.mdx b/docs/ros/api/sensors_api.mdx
new file mode 100644
index 000000000..ebb721982
--- /dev/null
+++ b/docs/ros/api/sensors_api.mdx
@@ -0,0 +1,54 @@
+---
+title: ROS 2 Sensors API
+sidebar_label: Sensors API
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+:::note
+
+The '#' in the topic represents the index of the sensor. Indexing begins at 0 and will increment for
+each new sensor of that type that is added. Internal sensors such as IMU's will be indexed first.
+
+:::
+
+## 2D Lidar topics
+
+| Topic | Message type | Description | QoS |
+| :---------------------- | :----------------------------------------------------------------------------------------------------------- | :-------------- | :-------------------------------------------- |
+| sensors/lidar2d\_#/scan | [sensor_msgs/LaserScan](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/LaserScan.msg) | Lidar scan data | [System Default](overview.mdx#system-default) |
+
+## 3D Lidar topics
+
+| Topic | Message type | Description | QoS |
+| :------------------------ | :--------------------------------------------------------------------------------------------------------------- | :-------------------- | :-------------------------------------------- |
+| sensors/lidar3d\_#/points | [sensor_msgs/PointCloud2](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/PointCloud2.msg) | Lidar pointcloud data | [System Default](overview.mdx#system-default) |
+| sensors/lidar3d\_#/scan | [sensor_msgs/LaserScan](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/LaserScan.msg) | Lidar scan data | [System Default](overview.mdx#system-default) |
+
+## Camera topics
+
+| Topic | Message type | Description | QoS |
+| :---------------------------------- | :--------------------------------------------------------------------------------------------------------------- | :-------------- | :-------------------------------------------- |
+| sensors/camera\_#/color/image | [sensor_msgs/Image](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Image.msg) | Raw RGB image | [System Default](overview.mdx#system-default) |
+| sensors/camera\_#/color/camera_info | [sensor_msgs/CameraInfo](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/CameraInfo.msg) | Camera Info | [System Default](overview.mdx#system-default) |
+| sensors/camera\_#/depth/image | [sensor_msgs/Image](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Image.msg) | Raw depth image | [System Default](overview.mdx#system-default) |
+| sensors/camera\_#/depth/camera_info | [sensor_msgs/CameraInfo](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/CameraInfo.msg) | Camera Info | [System Default](overview.mdx#system-default) |
+| sensors/camera\_#/points | [sensor_msgs/PointCloud2](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/PointCloud2.msg) | Pointcloud data | [System Default](overview.mdx#system-default) |
+| sensors/camera\_#/imu | [sensor_msgs/Imu](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Imu.msg) | IMU data | [System Default](overview.mdx#system-default) |
+
+## IMU topics
+
+| Topic | Message type | Description | QoS |
+| :---------------------- | :------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------- | :-------------------------------------------- |
+| sensors/imu\_#/data_raw | [sensor_msgs/Imu](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Imu.msg) | Raw IMU orientation, angular velocity, and linear acceleration data | [Sensor Data](overview.mdx#sensor-data) |
+| sensors/imu\_#/data | [sensor_msgs/Imu](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Imu.msg) | Filtered IMU orientation, angular velocity, and linear acceleration data | [System Default](overview.mdx#system-default) |
+| sensors/imu\_#/mag | [sensor_msgs/MagneticField](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/MagneticField.msg) | IMU magnetic field data | [System Default](overview.mdx#system-default) |
+
+## GPS topics
+
+| Topic | Message type | Description | QoS |
+| :----------------- | :----------------------------------------------------------------------------------------------------------- | :--------------------- | :-------------------------------------------- |
+| sensors/gps\_#/fix | [sensor_msgs/NavSatFix](https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/NavSatFix.msg) | Navsat Fix information | [System Default](overview.mdx#system-default) |
+
+
diff --git a/docs/ros/config/_category_.json b/docs/ros/config/_category_.json
new file mode 100644
index 000000000..f4eab1657
--- /dev/null
+++ b/docs/ros/config/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Robot Configuration",
+ "position": 2
+}
diff --git a/docs/ros/config/customization.mdx b/docs/ros/config/customization.mdx
new file mode 100644
index 000000000..f5ad5a89f
--- /dev/null
+++ b/docs/ros/config/customization.mdx
@@ -0,0 +1,164 @@
+---
+title: Customization Package
+sidebar_label: Customization Package
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+The Clearpath configuration system provides a wide range of configuration options, but it is still limited to the set of standard payloads that are supported natively. However, it is possible to add custom meshes, URDF's, and launch files. To do so, it is recommended to follow the standard presented here to create a customization package.
+
+A customization package is a ROS source package, built from the ground up, specifically to extend the Clearpath configuration of a specific robot. The customization package contains two sub-packages, the description and bringup packages. The description package contains all extra visual descriptions of the robot, such as meshes and URDFs of payloads. The bringup package contains all launch and parameter files for payloads on the robot. The reason behind this division is to allow remote users that are interested only in visualizing and commanding the robot to only require the description package.
+
+Directory structure of a customization package.
+```
+project/
+├── project_description/
+│ ├── CMakeLists.txt
+│ ├── package.xml
+│ ├── meshes/
+│ │ └── mesh.stl
+│ └── urdf/
+│ ├── device.urdf.xacro
+│ └── project_description.urdf.xacro
+├── project_bringup/
+│ ├── CMakeLists.txt
+│ ├── package.xml
+│ ├── config/
+│ │ └── device.yaml
+│ └── launch/
+│ ├── device.launch.py
+│ └── project_bringup.launch.py
+├── .git/
+├── robot.yaml
+└── README.md
+```
+
+A secondary goal of the customization package is to serve as a repository that contains the entire configuration of a robot. Therefore, it is recommended to keep the `robot.yaml` configuration file in the top directory and to symbolically link this versioned file to the `/etc/clearpath/robot.yaml` on the robot.
+
+### Create the Package
+Create the package within the `colcon_ws`. See the [**workspace creation**](./workspaces.mdx) documentation for more information on setting it up.
+
+Start by creating the main directory. Its name should match the name of the project repository. For the following examples, the project name will simply be a placeholder, `project`.
+```bash
+cd ~/colcon_ws/src
+mkdir project
+```
+
+Within this project directory, create the description and bringup packages.
+```bash
+cd ~/colcon_ws/src/project
+ros2 pkg create project_description --description "Project description package" --license "BSD-3-Clause"
+ros2 pkg create project_bringup --description "Project bringup package" --license "BSD-3-Clause"
+```
+
+Then, create the sub-directories within each of the packages.
+```bash
+cd ~/colcon_ws/src/project/project_description
+mkdir urdf meshes
+cd ~/colcon_ws/src/project/project_bringup
+mkdir config launch
+```
+
+For the final step, modify the `CMakeLists.txt` files in both packages to ensure that the description and bringup files are installed to the workspace.
+
+Add the following entry to the `project_description/CMakeLists.txt` file.
+```CMake
+install(DIRECTORY meshes urdf
+ DESTINATION share/${PROJECT_NAME}
+)
+```
+
+And, add the following entry to the `project_bringup/CMakeLists.txt` file.
+```CMake
+install(DIRECTORY config launch
+ DESTINATION share/${PROJECT_NAME}
+)
+```
+
+Now, all added files to the `meshes`, `urdf`, `config`, and `launch` directories will be installed to the `colcon_ws/install` directory, such that all other nodes will have access to these. Therefore, create
+
+### Include Package Description and Bringup in Configuration
+Once the packages have been setup and all customization files have been created and installed, it is possible to include these into the configuration file. By including these descriptions and bringups, the Clearpath configuration system will generate holistic, amalgamated files that will at launched at start-up.
+
+#### Directly Add Mesh to Configuration
+Meshes can be included directly or indirectly into the robot configuration. The direct approach is to add a `link` of type `mesh` in the configuration file and then specify the package name and path to the mesh. For example, in the directory structure exemplified above, there is a `mesh.stl` under the `meshes` directory in the `project_description` package. To directly add this `mesh.stl` to the configuration file, the following entry is included in `robot.yaml`.
+```yaml
+links:
+ mesh:
+ - name: mesh_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ visual:
+ package: project_description
+ path: meshes/mesh.stl
+```
+The location and orientation of the mesh can be set using the `parent`, `xyz`,
+and `rpy` parameters. The `name` of the link must be unique.
+
+#### Indirectly Add Mesh to Configuration through URDF
+Alternatively, meshes can be added indirectly through the URDF. In the description package, create a URDF that will include the mesh as a link, and then add that URDF to the `robot.yaml`. In the example directory above, there is a `project_description.urdf.xacro`. In this URDF, add the link and join it to the robot using a joint.
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+For more information on the URDF, see the ROS documentation on [links](https://wiki.ros.org/urdf/XML/link) and [joints](https://wiki.ros.org/urdf/XML/joint).
+
+Now that the mesh has been added to the file, the URDF can be included in the `robot.yaml`, by setting the extra URDF entry in the URDF
+```yaml
+platform:
+ extras:
+ urdf:
+ package: project_description
+ path: urdf/project_description.urdf.xacro
+```
+
+#### Adding Launch File to Configuration
+A launch file can be added to the configuration in the same way that a URDF was in the previous section.
+```yaml
+platform:
+ extras:
+ launch:
+ package: project_bringup
+ path: launch/project_bringup.launch.py
+```
+
+Only a single extra launch file can be set in the configuration file. However, it is possible to include multiple launch files within the selected one. From the example above, assume `device.launch.py` is a launch file that brings up a device with `device.yaml` parameters, and it is required that it is included in the main `project_bringup.launch.py`.
+```python
+def generate_launch_description():
+ # Package Directory
+ pkg_project_bringup = FindPackageShare('project_bringup')
+
+ # Launch File
+ device_launch = PathJoinSubstitution([pkg_project_bringup, 'launch', 'device.launch.py'])
+
+ # Include Launch
+ include_launch = IncludeLaunchDescription(PythonLaunchDescriptionSource([device_launch]))
+
+ # Launch Description
+ ld = LaunchDescription()
+ ld.add_action(include_launch)
+ return ld
+
+```
diff --git a/docs/ros/config/generators.mdx b/docs/ros/config/generators.mdx
new file mode 100644
index 000000000..e3bc53d41
--- /dev/null
+++ b/docs/ros/config/generators.mdx
@@ -0,0 +1,263 @@
+---
+title: Generators
+sidebar_label: Generators
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import Mermaid from '@theme/Mermaid';
+
+Part of the appeal of using the robot YAML configuration file is that it allows us to generate the necessary files
+to operate the robot at runtime. There are 4 types of files that need to be generated: bash shell scripts, URDF description files,
+launch files, and parameter files. Each file type has a generator which will use the [Clearpath Config](../../ros/ros.mdx#terminology) to figure out which files need to
+be created, and what the contents should be. Each generator also has a writer class which contains methods for writting formatted
+lines specific to the file type.
+
+:::note
+
+Generator scripts do not need to be modified by the user. Rather the user should modify their robot YAML file to suit their needs.
+
+:::
+
+### Bash
+
+The main bash script that needs to be generated is the `setup.bash` file. This file will source the Humble `setup.bash`, as well as any
+additional workspaces. It will also contain environment variables for setting up ROS 2. This file will be sourced by the `robot_upstart` job, as well
+as the user terminal. This way we can ensure that the bash environment of the upstart jobs matches the user's.
+
+### Description
+
+The description generator will generate a `robot.urdf.xacro` file which will define the robot. By parsing the robot YAML file, we can determine which
+platform the robot is using, as well as which mounts, accessories, and sensors will need to be added on top of the platform. This URDF file will later
+be used with the robot state publisher to publish all of the static transforms that make up the robot.
+
+### Semantic Description
+
+The semantic description generator will generate a `robot.srdf.xacro` and `robot.srdf` files with will define all manipulator groups, manipulator poses, and link collisions. By default, MoveIt! planners will check all links in the description to ensure collision free paths. If there are several links with complicated geometries, this will be a slow process. Therefore, the generator uses the collision matrix updater to disable the collisions of all links out of range of the manipulator groups defined and minimize the planning time.
+
+### Launch
+
+The launch generator creates ROS 2 [python launch files](https://docs.ros.org/en/humble/Tutorials/Intermediate/Launch/Creating-Launch-Files.html). It will create both the platform and sensor launch files by parsing the robot config. Typically, the generated launch file will include a default launch file, and pass in launch arguments as appropriate. Python classes have been defined for adding other launch files, nodes, and processes to the generated launch file, making it intuitive to use.
+
+### Parameter
+
+The parameter generator creates `.yaml` ROS parameter files that are used by the corresponding launch file. Each node has default parameters set that the user can overwrite by setting them in the robot configuration YAML.
+
+### Platform Generation
+By running the **bash**, **description**, **launch**, and **parameter** generators, the launch file and all necessary configuration files to run the platform nodes are created in the directory **/etc/clearpath/platform**. The top level launch file to start all platform related nodes is the **platform-service.launch.py**, which is generated in the **/etc/clearpath/platform/launch** directory by the **launch** generator. Each Clearpath platform robot has its own configuration files, but ultimately all parameter files generated in the same directory and the launch procedure is the same for every platform.
+
+Bash Generator}}
+ g_urdf{{Description Generator}}
+ g_launch{{Launch Generator}}
+ g_param{{Parameter Generator}}
+ %% Generated Files
+ bash([
])
+ subgraph Clearpath Generators
+ yaml-.-g_bash
+ yaml-.-g_urdf
+ yaml-.-g_launch
+ yaml-.-g_param
+ end
+ g_bash-->bash
+ g_urdf-->urdf
+ g_launch-->launch
+ g_param-->control
+ g_param-->localization
+ subgraph Clearpath Platform Service
+ bash-.->launch
+ urdf-.->launch
+ control-.->launch
+ localization-.->launch
+ end
+ classDef generator stroke-width:4px
+ class g_bash generator
+ class g_urdf generator
+ class g_param generator
+ class g_launch generator
+ `}
+/>
+
+### Sensors Generation
+Using the **parameter** and **launch** file generators, a pair of files is created for each sensor defined in the configuration file. Each sensor is enumerated given its order in sensor section of the **robot.yaml**. For example, if two cameras are added, then the first will be named **camera_0** and the second **camera_1**, irrespective of the model of camera. Each sensor launch file generated is included in the top level **sensors-service.launch.py** which is ran by the service.
+Launch Generator}}
+ g_param{{Parameter Generator}}
+ %% Generated Launch Files
+ sensor_launch[[
])
+ g_semantic_description-.->xacro
+ xacro-.-g_collision
+ g_collision-.->srdf
+ g_launch-.->launch
+ g_param-.->moveit
+ `}
+/>
+
+### Setup folder structure
+
+Once all files are generated, the resulting setup folder structure under `/etc/clearpath/` will look like this:
+- **manipulators**
+ - **launch**
+ - _manipulators-service.launch.py_
+ - **config**
+ - _moveit.yaml_
+- **platform**
+ - **launch**
+ - _platform-service.launch.py_
+ - **config**
+ - _control.yaml_
+ - _imu_filter.yaml_
+ - _localization.yaml_
+ - _teleop_interactive_markers.yaml_
+ - _teleop_joy.yaml_
+ - _twist_mux.yaml_
+- **sensors**
+ - **launch**
+ - _sensors-service.launch.py_
+ - _camera_0.launch.py_
+ - _camera_1.launch.py_
+ - ...
+ - **config**
+ - _camera_0.yaml_
+ - _camera_1.yaml_
+ - ...
+- _robot.srdf_
+- _robot.srdf.xacro_
+- _robot.urdf.xacro_
+- _robot.yaml_
+- _setup.bash_
diff --git a/docs/ros/config/img/husky_accessories_0.png b/docs/ros/config/img/husky_accessories_0.png
new file mode 100644
index 000000000..464d2ba29
Binary files /dev/null and b/docs/ros/config/img/husky_accessories_0.png differ
diff --git a/docs/ros/config/img/husky_mounts_0.png b/docs/ros/config/img/husky_mounts_0.png
new file mode 100644
index 000000000..59337c67f
Binary files /dev/null and b/docs/ros/config/img/husky_mounts_0.png differ
diff --git a/docs/ros/config/img/husky_mounts_1.png b/docs/ros/config/img/husky_mounts_1.png
new file mode 100644
index 000000000..0b51a3c4d
Binary files /dev/null and b/docs/ros/config/img/husky_mounts_1.png differ
diff --git a/docs/ros/config/img/husky_platform_0.png b/docs/ros/config/img/husky_platform_0.png
new file mode 100644
index 000000000..0be0dde66
Binary files /dev/null and b/docs/ros/config/img/husky_platform_0.png differ
diff --git a/docs/ros/config/img/husky_platform_1.png b/docs/ros/config/img/husky_platform_1.png
new file mode 100644
index 000000000..8f31095c5
Binary files /dev/null and b/docs/ros/config/img/husky_platform_1.png differ
diff --git a/docs/ros/config/img/husky_platform_2.png b/docs/ros/config/img/husky_platform_2.png
new file mode 100644
index 000000000..b9c38c500
Binary files /dev/null and b/docs/ros/config/img/husky_platform_2.png differ
diff --git a/docs/ros/config/img/husky_sample.png b/docs/ros/config/img/husky_sample.png
new file mode 100644
index 000000000..583d799e1
Binary files /dev/null and b/docs/ros/config/img/husky_sample.png differ
diff --git a/docs/ros/config/img/husky_sensors_0.png b/docs/ros/config/img/husky_sensors_0.png
new file mode 100644
index 000000000..d8a8db251
Binary files /dev/null and b/docs/ros/config/img/husky_sensors_0.png differ
diff --git a/docs/ros/config/img/husky_sensors_1.png b/docs/ros/config/img/husky_sensors_1.png
new file mode 100644
index 000000000..f9f7d4c6c
Binary files /dev/null and b/docs/ros/config/img/husky_sensors_1.png differ
diff --git a/docs/ros/config/img/husky_sensors_2.png b/docs/ros/config/img/husky_sensors_2.png
new file mode 100644
index 000000000..378e893c9
Binary files /dev/null and b/docs/ros/config/img/husky_sensors_2.png differ
diff --git a/docs/ros/config/img/live_yaml.gif b/docs/ros/config/img/live_yaml.gif
new file mode 100644
index 000000000..7eea50dce
Binary files /dev/null and b/docs/ros/config/img/live_yaml.gif differ
diff --git a/docs/ros/config/live.mdx b/docs/ros/config/live.mdx
new file mode 100644
index 000000000..d83ccb75b
--- /dev/null
+++ b/docs/ros/config/live.mdx
@@ -0,0 +1,67 @@
+---
+title: View and Edit the YAML
+sidebar_label: Live Configuration
+sidebar_position: 6
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Users familiar with Clearpath's robots, know we provide desktop packages that facilitate the viewing of robot models in RViz without needing to have a real robot. In ROS 2, the `view_model.launch.py` node will check and update the model and display the new changes in RViz.
+
+This functionality requires a desktop manager to be installed; in other words, these commands will not work on standard 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.
+
+On our robots, our standard working directory is: `/etc/clearpath`.
+
+On offboard computers, such as our users' computers, we recommend using `$HOME/clearpath`.
+
+However, you can choose whatever directory you'd like to use, just be mindful that contents may be deleted and recreated by our generator scripts. We will refer to this directory as the **setup_path**.
+
+Make sure to put your robot configuration file, `robot.yaml`, into the **setup_path**.
+> The configuration file must be named `robot.yaml`.
+
+You can get a sample `robot.yaml` file from the [Clearpath Configuration repository](https://github.com/clearpathrobotics/clearpath_config/).
+
+# Run the Node
+
+Running `view_model.launch.py` will generate the URDF of the robot from the `robot.yaml` and then start RViz.
+
+It will then monitor the `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 setup_path:=SETUP_PATH
+```
+> Replace `SETUP_PATH` with the path to the directory where the `robot.yaml` is located.
+
+> Do not include `~` in the `SETUP_PATH`, use `$HOME` instead.
+
+> Make sure that `SETUP_PATH` ends with `/`.
+
+# 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.
+
+
+
+
+ Live yaml
+
+
+
+> A drawback of using `tf_static` is that these static `TF` frames cannot be removed. Therefore, if you find yourself removing/deleting sections of the model, the mesh will be removed from the model, but the old TF frames will remain unchanged.
diff --git a/docs/ros/config/services.mdx b/docs/ros/config/services.mdx
new file mode 100644
index 000000000..b51481749
--- /dev/null
+++ b/docs/ros/config/services.mdx
@@ -0,0 +1,32 @@
+---
+title: Services
+sidebar_label: Services
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+To run all ROS 2 nodes in the background and from boot, we use [robot_upstart](https://github.com/clearpathrobotics/robot_upstart/tree/foxy-devel) to install
+the launch files as [systemd](https://manpages.ubuntu.com/manpages/jammy/en/man5/systemd.service.5.html) services. In ROS 1 there was a single `ros` service that
+ran everything. For ROS 2 Humble, we have split this into three separate services:
+[Platform](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_robot/services/clearpath-platform.service),
+[Sensors](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_robot/services/clearpath-sensors.service), and
+[Robot](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_robot/services/clearpath-robot.service).
+
+### Clearpath Platform
+
+The `clearpath-platform` service launches the `platform-service.launch.py` file found under `/etc/clearpath/platform/launch/`. This will launch the nodes
+required to operate the base platform, such as control, teleop, localization, and more. Running this service alone is enough to drive the robot, visualise it
+in Rviz, and get platform data. This service can be stopped or started without interrupting the sensor service.
+
+### Clearpath Sensors
+
+The `clearpath-sensors` service launches the `sensors-service.launch.py` file found under `/etc/clearpath/sensors/launch/`. This will launch any
+sensors defined in the robot YAML. This service can be stopped or started without interrupting the platform service.
+
+### Clearpath Robot
+
+The `clearpath-robot` service is the "parent" service of `clearpath-platform` and `clearpath-sensors`. If it is restarted, then both the platform and sensors services
+will restart. This service will run all of the [generators](generators.mdx) in the `PreExec` step, before allowing the two dependent services to start. While
+the platform and sensors services are running, the robot service will periodically check for changes in the `robot.yaml` file. If a change is detected
+the service restarts, re-generating all files and restarting the platform and sensors services.
diff --git a/docs/ros/config/workspaces.mdx b/docs/ros/config/workspaces.mdx
new file mode 100644
index 000000000..80a64eea6
--- /dev/null
+++ b/docs/ros/config/workspaces.mdx
@@ -0,0 +1,77 @@
+---
+title: Workspace Configuration
+sidebar_label: Workspace
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+All ROS packages that are required to be built from source must be built within a ROS workspace. A workspace is directory structure that standardizes and streamlines the build process of ROS packages. See the official ROS 2 Humble workspace documentation for more information. In the following sections, we will cover the steps required to build a workspace.
+
+# Creating a Workspace
+As a standard at Clearpath, name the workspace the `colcon_ws` and create it in the home directory.
+```bash
+cd ~
+mkdir -p colcon_ws/src
+```
+
+Clone all packages into the source directory, `~/colcon_ws/src`.
+
+# Building a Workspace
+Before building the workspace, use `rosdep` to install all required dependencies.
+```bash
+cd ~/colcon_ws
+rosdep install --from-paths src --ignore-src -r
+```
+
+The `--from-paths` argument defines the source directory where the packages that were installed from source are located.
+The `--ignore-src` flag indicates that dependencies found within the `--from-paths` directory will be used instead of trying to install binary versions.
+The `-r` flag instructs `rosdep` to continue to install found packages even if some are not found or result in errors.
+
+After running the command above, `rosdep` might report errors of missing packages. These packages may need to be installed from source or may not be required to build the package. However, these issues are on a case by case basis.
+
+Once dependencies are installed, it is possible to build the workspace.
+
+It is recommended to install the packages using symbolic links. These links will allow editing the content of file in the `src` packages, such as launch, URDF, or parameter files, without needing to rebuild the workspace. This is done by setting the `--symlink-install` flag.
+
+Furthermore, it is also recommended to build packages from source if debugging is not required. This is done by adding the arguments `--cmake-args -DCMAKE_BUILD_TYPE=Release`.
+
+**Release build with symbolic link install:**
+```bash
+cd ~/colcon_ws
+colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
+```
+
+If building a package that has already been installed, it is required to allow overriding the existing version. To do so, use the `--allow-overriding` flag followed by the name of packages to override separated by spaces.
+
+**Release build with symbolic link install that overrides existing packages:**
+```bash
+cd ~/colcon_ws
+colcon build --allow-overriding PKG_NAME_1 [PKG_NAME_2] --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
+```
+
+Lastly, it is also possible to build a single package at a time. This is particularly useful when working on a single package that requires rebuilding while several other packages in the workspace do not need to be rebuilt.
+
+**Single package release build with symbolic link install and override:**
+```bash
+cd ~/colcon_ws
+colcon build --packages-select PKG_NAME --allow-overriding PKG_NAME --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
+```
+
+# Source the Workspace
+Once the workspace has been built sucessfully, the workspace needs to be sourced before ROS commands can be used to launch any of the nodes of the packages built. To do so:
+```bash
+source ~/colcon_ws/install/setup.bash
+```
+
+It is necessary to source the workspace in every terminal instance. Alternatively, it is recommended to add the sourcing command to the `~/.bashrc` file such that the workspace is automatically sourced whenever a terminal is instantiated.
+
+It is also necessary to add the path to the workspace setup file into the Clearpath configuration file. To do so add the following entry into the `robot.yaml` file:
+```yaml
+system:
+ ros2:
+ workspaces:
+ - "/home/administrator/colcon_ws/install/setup.bash"
+```
+Replace `administrator` in the path with the name of the user in whose home directory the workspace was added. For more information on the Clearpth configuration system see the [**Robot YAML**](./yaml/system.mdx) documentation.
+
diff --git a/docs/ros/config/yaml/_category_.json b/docs/ros/config/yaml/_category_.json
new file mode 100644
index 000000000..22da69664
--- /dev/null
+++ b/docs/ros/config/yaml/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Robot YAML",
+ "position": 1
+}
diff --git a/docs/ros/config/yaml/links.mdx b/docs/ros/config/yaml/links.mdx
new file mode 100644
index 000000000..7ad3c1076
--- /dev/null
+++ b/docs/ros/config/yaml/links.mdx
@@ -0,0 +1,99 @@
+---
+title: Links
+sidebar_label: Links
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import LinkFrame from "/docs_versioned_docs/version-ros2humble/components/yaml/links/frame.mdx";
+import Box from "/docs_versioned_docs/version-ros2humble/components/yaml/links/box.mdx";
+import Cylinder from "/docs_versioned_docs/version-ros2humble/components/yaml/links/cylinder.mdx";
+import Mesh from "/docs_versioned_docs/version-ros2humble/components/yaml/links/mesh.mdx";
+import Sphere from "/docs_versioned_docs/version-ros2humble/components/yaml/links/sphere.mdx";
+
+Links are any URDF primitive.
+:::tip keep the frames in mind:
+ Just as is the case in URDF, links have their frame at the center of the primitive. In other words, you will need to slide up all links by half their height to have it "sit" on its parent link.
+:::
+
+## Frame
+Just a link without any geometry.
+
+
+## Box
+A box of defined size.
+
+
+## Cylinder
+A cylinder of defined height and radius.
+
+
+## Sphere
+A sphere of defined radius.
+
+
+## Mesh
+Include your custom mesh without creating a URDF of your own. You can either provide an absolute link
+to the mesh file or if it is included in a ROS 2 package, then you can provide both the package name
+and relative link to the install location within the package.
+
+If you prefer to add a URDF instead, then you can link it directly through the [`platform.extras`](platform/extras.mdx) entry.
+
+
+## Sample
+
+
+ Sample A200 Links Section
+
+
+
+
+
+ Husky A200 with Open User Bay
+
+
+
+ In this sample, we will use links to add thin **box** to cover up the user bay.
+
+ We add an entry under the **box** list:
+
+ ```yaml
+ box:
+ - name: user_bay_cover
+ parent: top_plate_link # add it to the top_plate_link
+ xyz: [0.0, 0.0, 0.00735] # move it up 6.35mm (thickness of top plate) and move it up 1mm (half height of the box)
+ rpy: [0.0, 0.0, 0.0]
+ size: [0.4, 0.4, 0.002] # length 400mm, width 400mm and 2mm thick.
+ ```
+
+
+
+
+ Husky A200 with Covered User Bay
+
+
+
+ We leave the rest of the lists all empty, for the resulting links section:
+
+ ```yaml
+ links:
+ box:
+ - name: user_bay_cover
+ parent: top_plate_link
+ xyz: [0.0, 0.0, 0.00735]
+ rpy: [0.0, 0.0, 0.0]
+ size: [0.4, 0.4, 0.002]
+ cylinder: []
+ frame: []
+ mesh: []
+ sphere: []
+ ```
+
+
+
diff --git a/docs/ros/config/yaml/manipulators.mdx b/docs/ros/config/yaml/manipulators.mdx
new file mode 100644
index 000000000..b9a3ab6e3
--- /dev/null
+++ b/docs/ros/config/yaml/manipulators.mdx
@@ -0,0 +1,41 @@
+---
+title: Manipulators
+sidebar_label: Manipulators
+sidebar_position: 8
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import KinovaGen3Lite from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_gen3_lite.mdx";
+import KinovaGen36Dof from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_gen3_6dof.mdx";
+import KinovaGen37Dof from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_gen3_7dof.mdx";
+import Kinova2FLite from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/kinova_2f_lite.mdx";
+import Robotiq2F85 from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/robotiq_2f_85.mdx";
+import Robotiq2F140 from "/docs_versioned_docs/version-ros2humble/components/yaml/manipulators/robotiq_2f_140.mdx";
+
+
+Manipulators include all robotic arms and grippers. Unlike sensors, manipulators are not controlled by external drivers. Instead, a hardware controller must be loaded into the controller manager to handle the joint interface to move the specific manipulator joints.
+
+Additionally, MoveIt! must be launched to plan paths and move manipulators to a given pose.
+
+Every arm can have at most one gripper, and grippers can only be added to an existing arm. This way, depending on the arm and the gripper, the configuration system can determine whether the arm handles communication with the gripper or whether it must be done through an external connection directly to the robot computer.
+
+## Kinova Arms {#kinova-arms}
+
+
+
+
+
+
+
+
+
+## Kinova Grippers {#kinova-grippers}
+
+
+
+## Robotiq Grippers {#robotiq-grippers}
+
+
+
+
+
diff --git a/docs/ros/config/yaml/mounts.mdx b/docs/ros/config/yaml/mounts.mdx
new file mode 100644
index 000000000..3eb7fc666
--- /dev/null
+++ b/docs/ros/config/yaml/mounts.mdx
@@ -0,0 +1,182 @@
+---
+title: Mounts
+sidebar_label: Mounts
+sidebar_position: 6
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import BracketHorizontal from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/bracket_horizontal.mdx";
+import BracketLarge from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/bracket_large.mdx";
+import BracketVertical from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/bracket_vertical.mdx";
+import DiskPost from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/disk_post.mdx";
+import Disk from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/disk.mdx";
+import FathPivot from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/fath_pivot.mdx";
+import PostDual from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/post_dual.mdx";
+import PostQuad from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/post_quad.mdx";
+import PostSingle from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/post_single.mdx";
+import Riser1x7 from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/riser_1x7.mdx";
+import Riser4x4 from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/riser_4x4.mdx";
+import Riser8x7 from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/riser_8x7.mdx";
+import SickInverted from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/sick_inverted.mdx";
+import SickUpright from "/docs_versioned_docs/version-ros2humble/components/yaml/mounts/sick_upright.mdx";
+
+Most sensors can use similar mounting structures. Therefore, we want to keep mounts separate from sensors, such that users could attach their own sensors to existing mounts.
+
+## Riser
+A mounting plate with the defined number of rows and columns of the PACS™ **80 mm X 80 mm** grid.
+
+:::warning not available without pacs:
+ At this time, you will **need to use the PACS™ top plate**, only available using the `a200.top_plate` with `model: pacs`, to add these riser mounts. See the [**platform**](./platform/attachments/overview.mdx) section for more information.
+:::
+
+### Preset Risers
+These are the most common riser sizes; therefore, we have accurate models of these plates.
+
+#### 8 X 7 Riser
+
+
+#### 1 X 7 Riser
+
+
+### Custom Risers
+To promote flexibility, the size of the risers can be changed to any size; however, there are no models for these, and instead will be generated using primitives.
+
+For example, we can add a riser with a 4 by 4 grid:
+
+
+## Bracket
+Brackets are small plates with **80 mm X 80 mm** screw holes that can be used to attach it to the PACS™ gird. They come in three different models.
+
+The **horizontal** and **vertical** models have screw holes to attach all small sensors such as camera, lidars, and IMUs.
+
+The **large** model has screw holes to attach larger sensors such as the SwiftNav Duro receivers.
+
+### Horizontal Bracket
+
+
+### Vertical Bracket
+
+
+### Large Bracket
+
+
+## Fath Pivot
+Camera mounts with a single joint that can be adjusted to change the pitch of the camera. The angle of the joint is set using the **angle** parameter.
+
+
+## SICK Mounts
+These mounts are specifically designed to mount SICK LiDARs, but can be used for other sensors if required.
+The orientation of the LiDAR on the mount can be set to either `upright` or `inverted`
+
+### Upright
+
+
+### Inverted
+
+
+## Post
+Posts are vertical extrusion rails to where sensors can be added.
+
+These can be single, dual, and quad legs.
+
+### Single
+
+
+### Dual
+
+
+### Quad
+
+
+## Disk
+Disk plates are used for circular sensors, such as the Velodyne LiDARs.
+
+
+We can also lift the **disk** by using a **post**.
+
+
+
+## Sample
+
+
+ Sample A200 Mounts Section
+
+
+
+
+
+ Husky A200 with Covered User Bay
+
+
+
+ In this sample, we will add a **bracket** to mount a LiDAR to the front of the **Husky A200**.
+
+ We select the **_top_plate_mount_d1_**, in other words, the middle (**d**), front (**1**), 80 mm X 80 mm mounting location on the **PACS** top plate.
+
+ ```yaml
+ bracket:
+ - parent: top_plate_mount_d1
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ model: horizontal
+ ```
+
+
+
+
+ Husky A200 with D1 Bracket
+
+
+
+ Then, we want to add a camera to the sensor arch. However, we will complicate things by adding it upside down to the extrusion.
+
+ We choose a **fath_pivot** mount, and then we set its **parent** to the **_sensor_arch_mount_**.
+
+ Using the **xyz** entry, we lower the mount by 21 mm to get it under the sensor arch; then, we roll it by $\pi$ to get it upside down.
+
+ ```yaml
+ fath_pivot:
+ - parent: sensor_arch_mount # mount atop the sensor arch
+ xyz: [0.0, 0.0, -0.021] # lower pivot mount to below the sensor arch
+ rpy: [3.1415, 0.0, 0.0] # roll pivot mount to flip it upside down
+ angle: 0.0
+ ```
+
+
+
+
+ Husky A200 with upside down Fath Pivot Mount
+
+
+
+ Since we did not need a riser, we leave that section empty; the resulting **mounts** section:
+
+ ```yaml
+ mounts:
+ bracket:
+ - parent: top_plate_mount_d1
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ model: horizontal
+ fath_pivot:
+ - parent: sensor_arch_mount
+ xyz: [0.0, 0.0, -0.021]
+ rpy: [3.1415, 0.0, 0.0]
+ angle: 0.0
+ riser: []
+ sick: []
+ post: []
+ disk: []
+ ```
+
+
+
diff --git a/docs/ros/config/yaml/overview.mdx b/docs/ros/config/yaml/overview.mdx
new file mode 100644
index 000000000..33a36d801
--- /dev/null
+++ b/docs/ros/config/yaml/overview.mdx
@@ -0,0 +1,188 @@
+---
+title: Robot YAML Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Our robots provide users with a wide range of customization options: sensors, sensor mounting structures, and custom-made parts. Matching the flexibility of our hardware, Clearpath's ROS 2 system is designed to keep all these customization decisions in a single configuration file.
+
+The **Clearpath Robot Configuration YAML**, or `robot.yaml` for short, contains all pertinent information to the entire robot system, allowing robot builders and users to quickly and easily modify any ROS 2 component.
+
+## Outline
+
+The `robot.yaml` is composed of five major sections:
+1. [**system**](./system.mdx) level information such as the robot's hostname, IP, and ROS middleware implementation.
+2. [**platform**](./platform/overview.mdx) level configurations such as robot specific mounting structures and parameters.
+3. [**links**](./links.mdx) of standard URDF primitives such as boxes, cylinders, and meshes.
+4. [**mounts**](./mounts.mdx) are predefined, generic, sensor mounting structures.
+5. [**sensors**](./sensors/overview.mdx) are selected from an inventory of Clearpath supported sensors.
+
+Additionally, there are two other, required parameters:
+
+1. The robot's [**serial_number**](./serial.mdx); which is used to determine the model and version.
+2. The configuration **version** to use, as future updates are released.
+
+## Sample
+
+
+
+
+ Sample customization, Husky A200
+
+
+
+Below is the sample **Husky A200** robot YAML of the robot displayed above. In the following sections, we will reference each and every component of this sample file, and show how to robot looks as we build it up.
+
+Find more samples `robot.yaml` configuration files in the [Clearpath Configuration repository](https://github.com/clearpathrobotics/clearpath_config/).
+
+You can also skip to each section to get an explanation of each part of the sample configuration:
+
+1. [**Serial Number Sample**](./serial.mdx#sample)
+2. [**System Sample**](./system.mdx#sample)
+3. [**Platform Sample**](./platform/overview.mdx#sample)
+4. [**Links Sample**](./links.mdx#sample)
+5. [**Mounts Sample**](./mounts.mdx#sample)
+6. [**Sensors Sample**](./sensors/overview.mdx#sample)
+
+
+ Sample A200 YAML
+
+
diff --git a/docs/ros/config/yaml/platform/_category_.json b/docs/ros/config/yaml/platform/_category_.json
new file mode 100644
index 000000000..004978069
--- /dev/null
+++ b/docs/ros/config/yaml/platform/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Platform",
+ "position": 4
+}
diff --git a/docs/ros/config/yaml/platform/attachments/_category_.json b/docs/ros/config/yaml/platform/attachments/_category_.json
new file mode 100644
index 000000000..2687e472b
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Attachments",
+ "position": 2
+}
diff --git a/docs/ros/config/yaml/platform/attachments/a200.mdx b/docs/ros/config/yaml/platform/attachments/a200.mdx
new file mode 100644
index 000000000..a45860411
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/a200.mdx
@@ -0,0 +1,50 @@
+---
+title: A200 Attachments
+sidebar_label: A200
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import A200Bumper from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/bumper.mdx";
+import A200SensorArch300 from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/sensor_arch_300.mdx";
+import A200SensorArch510 from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/sensor_arch_510.mdx";
+import A200TopPlateDefault from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/top_plate_default.mdx";
+import A200TopPlateLarge from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/top_plate_large.mdx";
+import A200TopPlatePACS from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/top_plate_pacs.mdx";
+
+## Bumper
+The A200 can have bumpers of a variable length. By setting the `extension` parameter, the bumper can be extended if required.
+
+By default, we have two bumpers, on the front and rear of the robot.
+
+
+
+
+## Top Plate
+The A200 has three types of top plates that modify the mounting surface of the robot.
+
+#### Default
+The **default** top plate is mounted atop a user rail that can be used to mount certain payload inside the chassis and right below the top plate.
+
+
+
+#### Large
+The **large** top plate does not have a user rail and is primarily used to mount larger payloads such as manipulators on the robot.
+
+
+
+#### PACS
+The **pacs** top plate does not have a user rail. It has an opening to access the user bay within the chassis. It comes with the grid of mounting holes of the PACS™ **80mm x 80mm** grid.
+
+
+
+## Sensor Arch
+The A200 has two types of sensor archs which are used to mount sensors from a vantage point.
+
+#### Sensor Arch 300
+
+
+
+#### Sensor Arch 510
+
+
diff --git a/docs/ros/config/yaml/platform/attachments/dx1X0.mdx b/docs/ros/config/yaml/platform/attachments/dx1X0.mdx
new file mode 100644
index 000000000..39b5fceee
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/dx1X0.mdx
@@ -0,0 +1,12 @@
+---
+title: DD1X0 and DO1X0 Attachments
+sidebar_label: DD1X0 & DO1X0
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import DX1X0TopPlate from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/dx1X0/top_plate.mdx";
+
+## Top Plate
+
+
diff --git a/docs/ros/config/yaml/platform/attachments/j100.mdx b/docs/ros/config/yaml/platform/attachments/j100.mdx
new file mode 100644
index 000000000..cda300bcb
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/j100.mdx
@@ -0,0 +1,34 @@
+---
+title: J100 Attachments
+sidebar_label: J100
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import J100FenderDefault from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/j100/fender_default.mdx";
+import J100FenderSensor from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/j100/fender_sensor.mdx";
+import J100TopPlateArkEnclosure from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/j100/top_plate_ark_enclosure.mdx";
+
+## Fenders
+There are two types of fenders that can be equipped on the **J100** platform.
+
+#### Default Fenders
+The **default** fenders are the standard fenders that come with every **J100**.
+
+The front and rear fender entries are indepenent from each other such that they can be modified independently.
+
+
+
+#### Sensor Fenders
+The **default** fenders are the standard fenders that come with every **J100**.
+
+The front and rear fender entries are indepenent from each other such that they can be modified independently.
+
+
+
+## Top Plate
+The Jackal only has one type of top plate. The ark enclosure.
+
+#### Ark Enclosure
+
+
diff --git a/docs/ros/config/yaml/platform/attachments/overview.mdx b/docs/ros/config/yaml/platform/attachments/overview.mdx
new file mode 100644
index 000000000..563a5f196
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/overview.mdx
@@ -0,0 +1,30 @@
+---
+title: Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+Each robot platform has its own unique set of attachments. To facilitate customization, any attachment from any robot platform can be added on any other robot platform.
+
+There is a default `parent` link at which these attachments are added. However, the `parent` link can be changed to wherever attachment needs to be placed.
+
+Additionally, all attachments can be moved around using the `xyz` parameter to translate and the `rpy` parameter to rotate.
+
+Each attachment requires two parameters. The `name` parameter that will define the name of the links and joints added to URDF, and the `type` parameter which defines which type of attachment is to be added.
+
+Some attachment types will have the same `type` parameter across different platforms. In that case, if you'd like to use the attachment that belongs to a specific platform, you will need to prefix the `type` parameter with the platform that it belongs to. For example, `top_plate` would become `a200.top_plate`. If no prefix is set, then the platform defined in the `serial_number` will be used.
+
+See the following pages for details:
+- [**A200 Attachments**](./a200.mdx):
+ - [**a200.bumper**](./a200.mdx#bumper)
+ - [**a200.top_plate**](./a200.mdx#top-plate)
+ - [**a200.sensor_arch**](./a200.mdx#sensor-arch)
+- [**J100 Attachments**](./j100.mdx):
+ - [**j100.fenders**](./j100.mdx#fenders)
+ - [**j100.top_plate**](./j100.mdx#top-plate)
+- [**W200 Attachments**](./w200.mdx):
+ - [**w200.bulkhead**](./w200.mdx#bulkhead)
+ - [**w200.arm_mount**](./w200.mdx#arm-mount)
+ - [**w200.generator**](./w200.mdx#generator)
diff --git a/docs/ros/config/yaml/platform/attachments/r100.mdx b/docs/ros/config/yaml/platform/attachments/r100.mdx
new file mode 100644
index 000000000..ff004ded6
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/r100.mdx
@@ -0,0 +1,22 @@
+---
+title: R100 Attachments
+sidebar_label: R100
+sidebar_position: 6
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import R100FAMS from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/r100/fams.mdx";
+import R100HAMS from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/r100/hams.mdx";
+import R100Tower from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/r100/tower.mdx";
+
+## Flat Arm Mounting Structure (FAMS)
+
+
+
+## Heavy Arm Mounting Structure (HAMS)
+
+
+
+## Dual Arm Tower
+
+
diff --git a/docs/ros/config/yaml/platform/attachments/w200.mdx b/docs/ros/config/yaml/platform/attachments/w200.mdx
new file mode 100644
index 000000000..74e073e6f
--- /dev/null
+++ b/docs/ros/config/yaml/platform/attachments/w200.mdx
@@ -0,0 +1,30 @@
+---
+title: W200 Attachments
+sidebar_label: W200
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import W200ArmMount from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/w200/arm_mount.mdx";
+import W200BulkheadArmMount from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/w200/bulkhead_arm_mount.mdx";
+import W200BulkheadDefault from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/w200/bulkhead_default.mdx";
+import W200Generator from "/docs_versioned_docs/version-ros2humble/components/yaml/attachments/w200/generator.mdx";
+
+## Bulkhead
+The Warthog bulkhead is used to cover payloads and to add a second surface to which to attach more payloads.
+
+#### Default {#default-bulkhead}
+
+
+
+#### Arm Mount {#arm-mount-bulkhead}
+
+
+
+## Arm Mount
+If instead of using the **bulkhead** to add an arm mount. We can add the arm mount independently using the following entry.
+
+
+
+## Generator
+
diff --git a/docs/ros/config/yaml/platform/battery.mdx b/docs/ros/config/yaml/platform/battery.mdx
new file mode 100644
index 000000000..591fc3fb5
--- /dev/null
+++ b/docs/ros/config/yaml/platform/battery.mdx
@@ -0,0 +1,107 @@
+---
+title: Battery
+sidebar_label: Battery
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+Each robot platform can support different types of batteries, and in different configurations. The configuration is how
+many batteries the robot has in series and parallel.A configuration of S2P1 indicates that there is one row of two batteries in series. S4P3
+indicates that there are 3 parallel rows of 4 batteries in series, for a total of 12 batteries.
+
+Some robots support "smart" batteries which have built in battery management system (BMS). If these batteries are specified, a corresponding driver node will
+be launched as part of the platform service. For batteries without a BMS, the [battery state estimator](https://github.com/clearpathrobotics/clearpath_robot/blob/main/clearpath_diagnostics/clearpath_diagnostics/battery_state/battery_state_estimator)
+node will be launched. This node will interpolate the state of charge of the robot from measured battery voltages.
+
+The battery state of the platform is available on the `platform/bms/state` topic.
+
+:::note
+
+For systems without a BMS, the state of charge should be treated as a rough estimate. This is especially true with Lead Acid batteries.
+
+:::
+
+
+
+
+
+| Battery | Chemistry | Nominal Voltage (V) | Capacity (Ah) | Configurations |
+|:-:|:-:|:-:|:-:|:-:|
+| `ES20_12C` | Lead Acid | 12.0 | 20.0 | S2P1 |
+| `HE2613` | Lithium Ion | 25.9 | 12.8 | S1P3 S1P4 |
+
+
+
+
+| Battery | Chemistry | Nominal Voltage (V) | Capacity (Ah) | Configurations |
+|:-:|:-:|:-:|:-:|:-:|
+| `HE2613` | Lithium Ion | 25.9 | 12.8 | S1P1 |
+
+
+
+
+| Battery | Chemistry | Nominal Voltage (V) | Capacity (Ah) | Configurations |
+|:-:|:-:|:-:|:-:|:-:|
+| `U1_35` | Lead Acid | 12.0 | 35.0 | S4P3 |
+| `NEC_ALM12V35` | Lithium Ion | 13.2 | 35.0 | S4P3 |
+| `VALENCE_U24_12XP` | Lithium Ion | 12.8 | 118.0 | S4P1 |
+| `VALENCE_U27_12XP` | Lithium Ion | 12.8 | 144.0 | S4P1 |
+
+
+
+
+
+
+
+
+
+For example for an A200:
+
+```yaml
+battery:
+ model: ES20_12C
+ configuration: S2P1
+```
diff --git a/docs/ros/config/yaml/platform/controller.mdx b/docs/ros/config/yaml/platform/controller.mdx
new file mode 100644
index 000000000..385be7fa7
--- /dev/null
+++ b/docs/ros/config/yaml/platform/controller.mdx
@@ -0,0 +1,17 @@
+---
+title: Controller
+sidebar_label: Controller
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+We support two types of controllers on all platforms:
+ - **ps4**: standard Playstation4 controller.
+ - **logitech**: Logitech F710
+
+Switching between each is done by setting the `controller` parameter under the `platform` tag.
+
+```yaml
+controller: ps4 # or logitech
+```
diff --git a/docs/ros/config/yaml/platform/extras.mdx b/docs/ros/config/yaml/platform/extras.mdx
new file mode 100644
index 000000000..fe77c3b7c
--- /dev/null
+++ b/docs/ros/config/yaml/platform/extras.mdx
@@ -0,0 +1,99 @@
+---
+title: Extras
+sidebar_label: Extras
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+Despite all current customization options, we still would like our users to be able to add-in their existing custom URDF to the robot platform URDF and pass in and overwrite parameters to all platform nodes.
+Extras have the following entries:
+
+- **urdf:**
+ - **package:** name of the ROS 2 package that contains the extras URDF (optional).
+ - **path:** relative path within the package or absolute path to robot extras URDF
+- **ros_parameters:** in YAML to pass in parameters to platform nodes. This is useful to change parameters such as the robot's velocity and acceleration.
+
+```yaml
+extras:
+ urdf:
+ package: package_name
+ path: relative/path/to/urdf/in/package.urdf.xacro # or can contain /absolute/path/to/urdf.urdf.xacro
+ launch:
+ package: package_name
+ path: relative/path/to/launch/in/package.launch.py
+ ros_parameters: {} # node parameters, see below
+```
+
+:::note
+Remember, absolute paths start with `/` and relative paths do not.
+:::
+
+### 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:
+ ros_parameters:
+ platform_velocity_controller:
+ wheel_radius: 0.1651
+ linear.x.max_velocity: 1.0
+ linear.x.min_velocity: -1.0
+ linear.x.max_acceleration: 3.0
+ linear.x.min_acceleration: -3.0
+ angular.z.max_velocity: 2.0
+ angular.z.min_velocity: -2.0
+ angular.z.max_acceleration: 6.0
+ angular.z.min_acceleration: -6.0
+```
+
+
+
+
+**J100 Jackal Controller Defaults:**
+```yaml
+platform:
+ extras:
+ ros_parameters:
+ platform_velocity_controller:
+ wheel_radius: 0.098
+ linear.x.max_velocity: 2.0
+ linear.x.min_velocity: -2.0
+ linear.x.max_acceleration: 20.0
+ linear.x.min_acceleration: -20.0
+ angular.z.max_velocity: 4.0
+ angular.z.min_velocity: -4.0
+ angular.z.max_acceleration: 25.0
+ angular.z.min_acceleration: -25.0
+```
+
+
+
+
+**W200 Warthog Controller Defaults:**
+```yaml
+platform:
+ extras:
+ ros_parameters:
+ platform_velocity_controller:
+ wheel_radius: 0.3
+ linear.x.max_velocity: 5.0
+ linear.x.min_velocity: -5.0
+ linear.x.max_acceleration: 50.0
+ linear.x.min_acceleration: -50.0
+ angular.z.max_velocity: 4.0
+ angular.z.min_velocity: -4.0
+ angular.z.max_acceleration: 40.0
+ angular.z.min_acceleration: -40.0
+```
+
+
+
diff --git a/docs/ros/config/yaml/platform/overview.mdx b/docs/ros/config/yaml/platform/overview.mdx
new file mode 100644
index 000000000..aa116e901
--- /dev/null
+++ b/docs/ros/config/yaml/platform/overview.mdx
@@ -0,0 +1,125 @@
+---
+title: Platform Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+Every robot platform has unique structures such as versatile sensor mounting solutions, wireless charging receivers, and waterproofing enclosures; we refer to these as **attachments**.
+
+Additionally, each robot also supports specific batteries and battery configurations that must be set accurately to ensure proper battery management.
+
+Furthermore, the robot platform nodes can be modified by the user through the extras section. In particular, an extra URDF can be appended to the robot's URDF, a launch file can be added to the robot's launch file, and ROS parameters can be modified directly by setting the key, value pairs.
+
+The platform section is divided into the following sections:
+- [**Attachments**](./attachments/overview.mdx)
+- [**Battery**](./battery.mdx)
+- [**Controller**](./controller.mdx)
+- [**Extras**](./extras.mdx)
+
+## Sample
+
+
+ Sample A200 Platform Section
+
+
+
+
+
+ Husky A200 with Default Top Plate
+
+
+
+ In this sample, we swapped the top plate from the **_default_** model to the **_pacs_** model. Notice all the links added by the **_pacs_** plate below, compared to the **_default_** plate above.
+
+ ```yaml
+ - name: top_plate
+ type: a200.top_plate
+ model: pacs # switched from 'default' to 'pacs'
+ parent: default_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ ```
+
+
+
+
+ Husky A200 with PACS Top Plate
+
+
+
+ Then, we added a sensor arch to add our sample sensors to. We can do this by adding the **attachment**, **sensor_arch** and setting the model to **_sensor_arch_300_**.
+
+ ```yaml
+ - name: sensor_arch
+ type: a200.sensor_arch
+ model: sensor_arch_300
+ parent: default_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ ```
+
+
+
+
+ Husky A200 with 300mm Sensor Arch
+
+
+
+ In terms of the **front_bumper** and **rear_bumper**, we left these as defaults. And, since we are not including any customization URDF or launch parameters; the resulting **platform** section look like this:
+
+ ```yaml
+ platform:
+ battery:
+ model: ES20_12C
+ configuration: S2P1
+ controller: ps4
+ attachments:
+ - name: front_bumper
+ type: a200.bumper
+ model: default
+ parent: front_bumper_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ extension: 0.0
+ - name: rear_bumper
+ type: a200.bumper
+ model: default
+ parent: rear_bumper_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ extension: 0.0
+ - name: top_plate
+ type: a200.top_plate
+ model: pacs
+ parent: default_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ - name: sensor_arch
+ type: a200.sensor_arch
+ model: sensor_arch_300
+ parent: default_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ extras:
+ urdf: {}
+ ros_parameters: {}
+ ```
+
+
+
diff --git a/docs/ros/config/yaml/sensors/_category_.json b/docs/ros/config/yaml/sensors/_category_.json
new file mode 100644
index 000000000..9c164ac7f
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Sensors",
+ "position": 7
+}
diff --git a/docs/ros/config/yaml/sensors/cameras.mdx b/docs/ros/config/yaml/sensors/cameras.mdx
new file mode 100644
index 000000000..c3e9830f5
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/cameras.mdx
@@ -0,0 +1,206 @@
+---
+title: Cameras
+sidebar_label: Cameras
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+import FlirBlackfly from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/flir_blackfly.mdx";
+import IntelRealsense from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/intel_realsense.mdx";
+import StereolabsZed from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/stereolabs_zed.mdx";
+
+Cameras are sensors that publish:
+ - Messages of type `sensor_msgs/Image` to the `/sensors/camera_#/color/image` topic.
+ - Messages of type `sensor_msgs/CameraInfo` to the `/sensors/camera_#/color/CameraInfo` topic.
+
+This broad definition allows us to label a variety of different cameras under a single banner. Stereo cameras, for example, could publish multiple images, disparity maps, and even pointclouds. Other cameras have in built inertial measurement units that publish `sensor_msgs/Imu`. Ultimately, all imaging devices fall into this category.
+
+
+## Compressed and Theora Topics
+Using the `image_transport` package and the [image_transport_plugins](https://github.com/ros-perception/image_transport_plugins), it is possible to send compressed and stream images using ROS 2 messages.
+
+For example, the color image topic will have multiple versions:
+```bash
+/a200_0000/sensors/camera_0/color/image
+/a200_0000/sensors/camera_0/color/compressed
+/a200_0000/sensors/camera_0/color/theora
+```
+
+:::note
+
+The same publisher handles all three of these message types. Limit the number of subscribers to minimize the load on the camera driver node.
+
+:::
+
+Compressed and theora types are not standard ROS 2 types, and therefore, it is required to decompress the images into standard `sensor_msgs/Image` messages before attempting to view them using standard tools such as RViz.
+
+The `clearpath_sensors` package has launch files to convert from and to these compressed transport types. Therefore, make sure to have the package installed on the computer that will be doing the decompressing:
+```bash
+sudo apt install ros-humble-clearpath-sensors
+```
+
+### Compressed
+Compressed image types are not serialized. These are images compressed using the JPEG format at 80% quality.
+
+Use the launch file `image_raw_to_compressed.launch.py` to compress `sensor_msgs/Image` messages into compressed messages.
+
+Assume we have the following image topic we would like to compress:
+```bash
+/a200_0000/sensors/camera_0/raw/image
+```
+
+Then, we can compress this image by launching the following:
+```bash
+ros2 launch clearpath_sensors image_raw_to_compressed.launch.py in_raw:=/a200_0000/sensors/camera_0/raw/image out_compressed:=/a200_0000/sensors/camera_0/raw/compressed
+```
+
+Now, we will have the following topics:
+```bash
+/a200_0000/sensors/camera_0/raw/image
+/a200_0000/sensors/camera_0/raw/compressed
+```
+
+To reverse this process, use the `image_compressed_to_raw.launch.py` to decompress back to `sensor_msgs/Image`:
+```bash
+ros2 launch clearpath_sensors image_compressed_to_raw.launch.py in_compressed:=/a200_0000/sensors/camera_0/raw/compressed out_raw:=/a200_0000/sensors/camera_0/decompressed/image
+```
+
+Now, we will have the following topics:
+```bash
+/a200_0000/sensors/camera_0/raw/image
+/a200_0000/sensors/camera_0/raw/compressed
+/a200_0000/sensors/camera_0/decompressed/image
+```
+
+### Theora
+Theora topics encode images into a video stream. By default, these streams have an 800 kb/s rate.
+
+Theora messages are not serialized, however, the first message after launching the encoder transmits the header packet. This header packet includes all of the encoding information required to decode the subsequent video packets. Therefore, if that first message is dropped or missed, then decoding the video packets back to images is not possible.
+
+Therefore, it is important to have the decoder node running before launching the encoder node, such that the former will not miss the header packet.
+
+:::warning
+Missing the header packet and being unable to decode the video packets is a known, long-standing issue with the `theora` image transport plugin. See this [issue](https://github.com/ros-perception/image_transport_plugins/issues/4) for more information.
+:::
+
+Assuming we have the following topic that we would like to stream:
+```bash
+/a200_0000/sensors/camera_0/raw/image
+```
+
+First, launch the decoder:
+```bash
+ros2 launch clearpath_sensors image_theora_to_raw.launch.py in_theora:=/a200_0000/sensors/camera_0/raw/theora out_raw:=/a200_0000/sensors/camera_0/decoded/image
+```
+
+Then, launch the encoder:
+```bash
+ros2 launch clearpath_sensors image_raw_to_theora.launch.py in_raw:=/a200_0000/sensors/camera_0/raw/image out_raw:=/a200_0000/sensors/camera_0/raw/theora
+```
+
+As long as the first header package is communicated without drops, the decoder will be able to decode and publish the raw image data:
+```bash
+/a200_0000/sensors/camera_0/raw/image
+/a200_0000/sensors/camera_0/raw/theora
+/a200_0000/sensors/camera_0/decoded/image
+```
+
+## Republishers
+All cameras publish to the `color/image` topic of type `sensor_msgs/Image`. However, we understand that sometimes this image may require downsampling, rectification, or cropping. To facilitate post processing images, we have included a method to easily add image processing nodes, leveraging composable nodes to maximize efficiency.
+
+:::note
+
+For more information on the image processing nodes see the [ROS wiki](https://wiki.ros.org/image_proc).
+
+:::
+
+Adding a republisher is simple.
+- Add a `republishers` tag under the `camera` entry.
+- Specify the `type` of republisher: `rectify` or `resize`.
+- Specify the `input` topic namespace. By default, it is `color` because the standard image topic will be `color/image`.
+- Specify the `output` topic namespace. By default, it is the type of the republisher: `{type}/image`.
+
+Configuring a republisher can be done by setting its node parameters using the `ros_parameters` section.
+- Under `ros_parameters` add an entry for the node `image_TYPE_INPUT`. Note, the node name depends on the `type` of republisher and the `input` name.
+- Add any parameter key, value pair to configure the node. Otherwise, it can be left empty to use defaults.
+
+### Rectify
+The `rectify` node takes the `camera_info` topic as a source of calibration parameters and applies an interpolation to rectify the raw images.
+
+To add a the rectify republisher add the following entries to the `camera` entry and its corresponding `ros_parameters` section.
+```yaml
+cameras:
+ - model: CAMERA_MODEL
+ republishers:
+ - type: rectify
+ input: color
+ output: rectify
+ ros_parameters:
+ CAMERA_NODE:
+ CAMERA_PARAMETER_KEY: CAMERA_PARAMETER_VALUE
+ image_rectify_color:
+ interpolation: 0
+```
+
+The `interpolation` parameter must be one of the following:
+- **0**: Nearest-neighbour.
+- **1**: Linear.
+- **2**: Cubic.
+- **3**: Area. Resampling using pixel area relation.
+- **4**: Lanczos4. Lanczos interpolation over 8x8 neighbourhood.
+
+:::note
+
+All UPPERCASE entries must be replaced based on the specific camera being used.
+
+:::
+
+### Resize
+The `resize` node uses the input image and resizes it.
+
+To add a resize republisher add teh following entreis to the `camera` entry and its corresponding `ros_parameters` section.
+```yaml
+cameras:
+ - model: CAMERA_MODEL
+ republishers:
+ - type: resize
+ input: color
+ output: resize
+ ros_parameters:
+ CAMERA_NODE:
+ CAMERA_PARAMETER_KEY: CAMERA_PARAMETER_VALUE
+ image_resize_color:
+ interpolation: 1
+ use_scale: True
+ scale_height: 1.0
+ scale_width: 1.0
+ height: -1
+ width: -1
+```
+If `use_scale` is set to `true`, then the `scale_height` and `scale_width` parameters will be used to resize the image. To reduce the size of the image by half, set `scale_height: 0.5` and `scale_width: 0.5`.
+
+If `use_scale` is set to `false`, then the `height` and `width` parameters will be used to resize the image. In this case, the exact pixel values of the desired image size can be passed.
+
+:::note
+
+The `scale_height` and `scale_width` parameters must be floating point values.
+
+The `height` and `width` parameters must be integer values.
+
+:::
+
+The `interpolation` parameters must be one of the following:
+- **0**: Nearest-neighbour.
+- **1**: Linear.
+- **2**: Cubic.
+- **3**: Area. Resampling using pixel area relation.
+- **4**: Lanczos4. Lanczos interpolation over 8x8 neighbourhood.
+
+## Intel Realsense
+
+
+## Flir BlackflyS
+
+
+## Stereolabs Zed
+
diff --git a/docs/ros/config/yaml/sensors/gps.mdx b/docs/ros/config/yaml/sensors/gps.mdx
new file mode 100644
index 000000000..b49731582
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/gps.mdx
@@ -0,0 +1,25 @@
+---
+title: GPS Receivers
+sidebar_label: GPS
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import Garmin18x from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/garmin_18x.mdx";
+import NovatelSmart6 from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/novatel_smart6.mdx";
+import NovatelSmart7 from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/novatel_smart7.mdx";
+import SwiftNavDuro from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/swiftnav_duro.mdx";
+
+GPS receivers are all devices that publish a `sensor_msgs/NavSatFix` message, which provides a latitude and longitude position.
+
+### SwiftNav Duro
+
+
+### Garmin 18X
+
+
+### Novatel Smart6
+
+
+### Novatel Smart7
+
diff --git a/docs/ros/config/yaml/sensors/imu.mdx b/docs/ros/config/yaml/sensors/imu.mdx
new file mode 100644
index 000000000..6a3a4d5da
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/imu.mdx
@@ -0,0 +1,21 @@
+---
+title: Inertial Measurment Units
+sidebar_label: IMU
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import CHRoboticsUM6 from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/chrobotics_um6.mdx";
+import RedShiftUM7 from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/redshift_um7.mdx";
+import MicrostrainIMU from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/microstrain_imu.mdx";
+
+Inertial measurement units are sensors that publish messages of the type `sensor_msgs/Imu`. These messages contain orientation, angular velocity, and/or linear acceleration depending on the device.
+
+### Microstrain IMU
+
+
+### CHRobotics UM6
+
+
+### Redshift UM7
+
diff --git a/docs/ros/config/yaml/sensors/lidar2d.mdx b/docs/ros/config/yaml/sensors/lidar2d.mdx
new file mode 100644
index 000000000..072ddb977
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/lidar2d.mdx
@@ -0,0 +1,17 @@
+---
+title: 2D Lidar
+sidebar_label: 2D Lidar
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import HokuyoUST from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
+import SickLMS1xx from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/sick_lms1xx.mdx";
+
+Two dimensional LiDARs provide a single planar scan, which is pusblished as a `sensor_msgs/LaserScan` message. It is important to accurately position the scanner in the visual description of the robot to ensure that the scanned plane is accurate with respect to the robot.
+
+### Hokuyo UST
+
+
+### SICK LMS1xx
+
diff --git a/docs/ros/config/yaml/sensors/lidar3d.mdx b/docs/ros/config/yaml/sensors/lidar3d.mdx
new file mode 100644
index 000000000..4377371ad
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/lidar3d.mdx
@@ -0,0 +1,13 @@
+---
+title: 3D Lidar
+sidebar_label: 3D Lidar
+sidebar_position: 5
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+import VelodyneLidar from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+Three dimensional LiDARs provide a pointcloud of all points detected by several planar scanners at various angles, which is published as a `sensor_msgs/PointCloud2` message. It is important to accurately position the LiDAR in the visual descriptiuon of the robot to ensured that the scanned points are accurate with respect to the robot.
+
+### Velodyne Lidar
+
diff --git a/docs/ros/config/yaml/sensors/overview.mdx b/docs/ros/config/yaml/sensors/overview.mdx
new file mode 100644
index 000000000..ccf1693ca
--- /dev/null
+++ b/docs/ros/config/yaml/sensors/overview.mdx
@@ -0,0 +1,190 @@
+---
+title: Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+At Clearpath, we have been migrating our large inventory of tested sensor drivers from ROS 1 to ROS 2.
+
+Sensors are split up into sections:
+
+- [**Cameras**](./cameras.mdx) publish **_sensor_msgs/Image_** messages
+- [**GPS**](./gps.mdx) publish **_sensor_msgs/NavSatFix_** messages
+- [**IMU**](./imu.mdx) publish **_sensor_msgs/Imu_** messages
+- [**LiDAR 2D**](./lidar2d.mdx) publish **_sensor_msgs/LaserScan_** messages
+- [**LiDAR 3D**](./lidar3d.mdx) publish **_sensor_msgs/PointCloud2_** messages
+
+In ROS 2, sensors use a `ros_parameters` YAML that contains all launch parameters for the driver node. To facilitate complete customization of these node parameters, the `ros_parameters` section, under every sensor entry, serves as a way to pass those key-value pairs to the corresponding node.
+
+By default, we pass tested parameters that are used on Clearpath robots.
+
+## Sample
+
+
+ Sample A200 Sensors Section
+
+
+
+
+
+ Husky A200 with upside down Fath Pivot Mount
+
+
+
+ In this sample, we first add the `velodyne_lidar` to the `sensor_arch_mount` by simply changing the parent link.
+
+ ```yaml
+ lidar3d:
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true
+ parent: sensor_arch_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.25
+ port: 2368
+ model: VLP16
+ velodyne_transform_node:
+ model: VLP16
+ fixed_frame: lidar3d_0_laser
+ target_frame: lidar3d_0_laser
+ ```
+
+
+
+
+ Husky A200 with LiDAR 3D on Sensor Arch
+
+
+
+ Next, we will add a `hokuyo_ust` to the **bracket** we added earlier. Since that is the first **bracket**, then it's mounting location will be: `bracket_0_mount`; setting the parent link of the sensor, we get:
+
+ ```yaml
+ lidar2d:
+ - model: hokuyo_ust
+ urdf_enabled: true
+ launch_enabled: true
+ parent: bracket_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ urg_node:
+ laser_frame_id: lidar2d_0_laser
+ ip_address: 192.168.131.20
+ ip_port: 10940
+ angle_min: -2.356
+ angle_max: 2.356
+ ```
+
+
+
+
+ Husky A200 with LiDAR 2D on D1 Bracket
+
+
+
+ For the final step, we will add an `intel_realsense` to the **fath_pivot** mount that we added. Because it is the first **fath_pivot**, it's mounting location will be: `fath_pivot_0_mount`; setting the parent link of the sensor:
+
+ ```yaml
+ camera:
+ - model: intel_realsense
+ urdf_enabled: true
+ launch_enabled: true
+ parent: fath_pivot_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ intel_realsense:
+ camera_name: camera_0
+ device_type: d435
+ serial_no: '0'
+ enable_color: true
+ rgb_camera.profile: 640,480,30
+ enable_depth: true
+ depth_module.profile: 640,480,30
+ pointcloud.enable: true
+ ```
+
+
+
+
+ Husky A200 with Intel RealSense
+
+
+
+ Leaving the other sections empty, leaves us with the full sensors section:
+
+ ```yaml
+ sensors:
+ camera:
+ - model: intel_realsense
+ urdf_enabled: true
+ launch_enabled: true
+ parent: fath_pivot_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ intel_realsense:
+ camera_name: camera_0
+ device_type: d435
+ serial_no: '0'
+ enable_color: true
+ rgb_camera.profile: 640,480,30
+ enable_depth: true
+ depth_module.profile: 640,480,30
+ pointcloud.enable: true
+ gps: []
+ imu: []
+ lidar2d:
+ - model: hokuyo_ust
+ urdf_enabled: true
+ launch_enabled: true
+ parent: bracket_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ urg_node:
+ laser_frame_id: lidar2d_0_laser
+ ip_address: 192.168.131.20
+ ip_port: 10940
+ angle_min: -2.356
+ angle_max: 2.356
+ lidar3d:
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true
+ parent: sensor_arch_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.25
+ port: 2368
+ model: VLP16
+ velodyne_transform_node:
+ model: VLP16
+ fixed_frame: lidar3d_0_laser
+ target_frame: lidar3d_0_laser
+
+ ```
+
+
+
diff --git a/docs/ros/config/yaml/serial.mdx b/docs/ros/config/yaml/serial.mdx
new file mode 100644
index 000000000..28b812c15
--- /dev/null
+++ b/docs/ros/config/yaml/serial.mdx
@@ -0,0 +1,27 @@
+---
+title: Serial Number
+sidebar_label: Serial Number
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+The Clearpath serial number is composed of two sections, separated by a hyphen, `-`, for example, `a200-0001`:
+1. An alpha-numerical code corresponding to the robot platform, `a200`
+2. Followed by an integer corresponding to the unit number, `0001`.
+
+At this moment, the supported robot platforms are:
+
+1. [Husky A200](../../../robots/outdoor_robots/husky/a200/user_manual_husky): `a200-0000`
+2. [Husky A300](../../../robots/outdoor_robots/husky/a300/user_manual_husky): `a300-0000`
+3. [Jackal J100](../../../robots/outdoor_robots/jackal/user_manual_jackal.mdx): `j100-0000`
+4. [Warthog W200](../../../robots/outdoor_robots/warthog/user_manual_warthog.mdx): `w200-0000`
+
+Every robot platform has specific attachments that are selected based on the serial number passed. Therefore, it is **required** that a serial number is specified in the `robot.yaml`.
+
+## Sample
+
+In our sample, we use a **Husky A200** and therefore have set our serial number to:
+
+```yaml
+serial_number: "a200-0000"
+```
diff --git a/docs/ros/config/yaml/system.mdx b/docs/ros/config/yaml/system.mdx
new file mode 100644
index 000000000..87d148233
--- /dev/null
+++ b/docs/ros/config/yaml/system.mdx
@@ -0,0 +1,143 @@
+---
+title: System
+sidebar_label: System
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+Proper networking setup is crucial in setting up the ROS 2 middleware and to ensure other onboard computers communicate reliably.
+
+## Username
+
+The username indicates the username that will be used to run all ROS nodes. If this username needs to be changed then the robot
+services must be reinstalled as directed in the [software installation instructions](../../installation/robot.mdx#robot-services).
+
+## Hosts {#hosts}
+
+The **hosts** section serves as a way to match hostnames to IP addresses. By default, Clearpath robots use the serial number as
+the hostname and have a default IP of `192.168.131.1`. This section must define ip addresses for all hostnames that appear in
+the remainder of the `robot.yaml` file.
+
+For example:
+
+```yaml
+ hosts:
+ - hostname: cpr-a200-0000 # The robot computer
+ ip: 192.168.131.1
+ - hostname: offboard-computer
+ ip: 192.168.131.5
+```
+
+## ROS 2 Environment
+
+The **ros2** section is necessary to set up the ROS 2 networking.
+
+| Key | Value / Datatype | Description |
+|:---:| :--------------: | ----------- |
+| **namespace** | string | Specified will be appended as a prefix to all sensor topics to prevent topics from being overloaded when multiple robots are on the same network and domain ID. |
+| **domain_id** | integer | Specifies the ROS 2 domain ID to use. |
+| **middleware** | [See Below](#middleware) | Specifies the ROS 2 middleware settings. |
+| **workspaces** | list | Indicates a list of custom ROS 2 workspaces that need to be sourced by specifying the path to the setup.bash or set to `[]` to leave it blank |
+
+For example:
+
+```yaml
+ros2:
+ username: administrator
+ namespace: a200_0000
+ domain_id: 0
+ middleware: # This section is described further below
+ implementation: rmw_fastrtps_cpp
+ workspaces:
+ - /home/administrator/colcon_ws/install/setup.bash # Path to the custom workspace
+```
+
+### Middleware
+
+The **middleware** section defines the which RMW Implementation to use and any related settings. To choose
+which implementation and discovery method is right for your project see [networking](../../networking/ros2-networking.mdx).
+
+| Key | Value / Datatype | Description |
+|:---:| :--------------: | ----------- |
+| **implementation** | `rmw_fastrtps_cpp` | Declares the RMW Implementation to use. Currently only supports `rmw_fastrtps_cpp`. |
+| **discovery** | `simple` or `server` | Select `simple` for simple discovery and `server` for discovery server. (Defaults to `simple`) |
+| **profile** | string | Advanced feature, allows an optional custom XML profile to be provided - RMW Implementation / vendor specific. |
+| **servers** | list | Provides a list of all discovery servers in the system and whether or not the robot should connect to them. |
+
+For example:
+
+```yaml
+middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: simple
+ profile: path/to/profile.xml
+ servers: # This section is described further below
+ - hostname: cpr-a200-0000
+```
+
+#### Servers
+
+This section is only used with eProsima Fast DDS Discovery Server (`implementation: rmw_fastrtps_cpp` and `discovery: server`).
+
+:::note
+
+This section must define *every single discovery server* in the system. This must include not only every discovery server
+that this robot is connecting to but also every discovery server that the offboard computer will connect to in the system.
+
+:::
+
+Each server can be defined with a number of different parameters:
+
+| Key | Value / Datatype | Description |
+|:---:| :--------------: | ----------- |
+| **hostname** | string | The hostname of the computer that is hosting the server (must be in the [hosts](#hosts) list). |
+| **port** | integer | The port at which to connect to the server (default is `11811`). |
+| **enabled** | `True` or `False` | This indicates whether or not the robot should connect to this server and, if the hostname matches the computer's own hostname, whether or not to launch the server (default is `True`). |
+
+For example:
+```yaml
+servers:
+ - hostname: cpr-a200-0000
+ port: 11811
+ enabled: True
+```
+
+## Sample
+
+
+ Sample A200 System Section
+
+
+ In our sample, we have a **Husky A200** platform whose primary computer has the hostname: `cpr-a200-0000` and IP: `192.168.131.1`.
+
+ By default, all Clearpath robots use the username `administrator` and the robot's namespace matches the `serial_number`.
+
+ ```yaml
+ system:
+ username: administrator
+ hosts:
+ - hostname: cpr-a200-0000
+ ip: 192.168.131.1
+ ros2:
+ namespace: a200_0000
+ domain_id: 0
+ middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: simple
+ workspaces: []
+ ```
+
+ At this point, with just the **serial_number** and **system** defined, our robot is just the standard **Husky A200** platform, and looks like this:
+
+
+
+
+ Default Husky A200
+
+
+
+
+
diff --git a/docs/ros/installation/_category_.json b/docs/ros/installation/_category_.json
new file mode 100644
index 000000000..e1a358ade
--- /dev/null
+++ b/docs/ros/installation/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Installation",
+ "position": 4
+}
diff --git a/docs/ros/installation/controller.mdx b/docs/ros/installation/controller.mdx
new file mode 100644
index 000000000..685e99e63
--- /dev/null
+++ b/docs/ros/installation/controller.mdx
@@ -0,0 +1,78 @@
+---
+title: Joystick Controller Pairing
+sidebar_label: Joystick Controller
+sidebar_position: 4
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Joystick controllers are used for teleoperation; they allow you to remotely drive the robot, whether it is a physical robot,
+or a simulated robot. The following instructions below detail how to pair different controllers to the robot's computer; however,
+these instructions can also be used to pair these controllers to your own computer.
+
+### PS4 Controller
+
+:::note
+
+If your robot comes with a PS4 controller, it will be paired already. Simply turn on the robot and turn on the controller.
+
+:::
+
+To re-pair the PS4 controller or pair a new PS4 controller:
+
+1. Install the python3-ds4drv package if it is not installed already. In terminal, run:
+
+```
+sudo apt-get install python3-ds4drv
+```
+
+2. Put the controller in pairing mode. Press and hold the PS and Share buttons on your controller until
+ the LED begins rapidly flashing white.
+3. Run the `ds4drv-pair` script to pair the controller to the computer. In terminal, run:
+
+```
+sudo ds4drv-pair
+```
+
+This script will scan for nearby Bluetooth devices, and pair automatically to the controller.
+
+Alternatively, if ds4drv-pair fails to detect the controller, you can pair the controller using `bluetoothctl`:
+
+1. Install the `bluez` package if it is not installed already. In terminal, run:
+
+```
+sudo apt-get install bluez
+```
+
+2. Run the `bluetoothctl` command. In terminal, run:
+
+```
+sudo bluetoothctl
+```
+
+3. Use `bluetoothctl` to scan for nearby devices. In the bluetooth control application, run:
+
+```
+agent on
+scan on
+```
+
+4. Put the controller in pairing mode. Press and hold the PS and Share buttons on your controller until
+ the LED begins rapidly flashing white.
+5. The bluetooth scan will display the MAC addresses of nearby devices. Determine which MAC address
+ corresponds to the controller and copy it. In the bluetooth control application, run:
+
+```
+scan off
+pair
+trust
+connect
+```
+
+The controller should now be paired.
+
+:::note
+
+Make sure to set the correct controller type in your [robot.yaml](../config/yaml/overview.mdx) file. See, [Joystick Controller](../config/yaml/platform/controller.mdx) setup in the Clearpath Configuration.
+
+:::
diff --git a/docs/ros/installation/img/wifi_interface.jpg b/docs/ros/installation/img/wifi_interface.jpg
new file mode 100644
index 000000000..c65f83974
Binary files /dev/null and b/docs/ros/installation/img/wifi_interface.jpg differ
diff --git a/docs/ros/installation/offboard_pc.mdx b/docs/ros/installation/offboard_pc.mdx
new file mode 100644
index 000000000..c776422d2
--- /dev/null
+++ b/docs/ros/installation/offboard_pc.mdx
@@ -0,0 +1,77 @@
+---
+title: Offboard Computer Setup
+sidebar_label: Offboard Computer
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+An offboard computer can be used to visualise and interact with the robot. The robot can also be
+[simulated](../tutorials/simulator/overview.mdx) on an offboard computer to safely test software before
+deploying to a physical robot.
+
+### Operating System (OS) {#operating-system}
+
+ROS 2 Humble uses [Ubuntu 22.04](https://releases.ubuntu.com/jammy/) as its Tier 1 operating system. Though other
+operating systems are supported,
+it is highly recommended to use Ubuntu 22.04. For the offboard computer, Ubuntu 22.04 Desktop should be installed.
+
+### Networking
+
+The offboard computer should be connected to the same Wi-Fi network as the robot computer, or should be connected via
+ethernet. If connected over ethernet, set the static IP of the offboard computer to use the `192.168.131.1/24` network
+with an IP address that won't interfere with other devices on the network, such as `192.168.131.99`.
+
+### ROS 2 Humble
+
+Follow the [official instructions](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html) for
+installing ROS 2 Humble from debian packages.
+
+### Clearpath Desktop metapackage
+
+Once the ROS 2 Humble has been installed, the [Clearpath Desktop](https://github.com/clearpathrobotics/clearpath_desktop)
+metapackage can be installed.
+
+```
+sudo apt install ros-humble-clearpath-desktop
+```
+
+This package will install launch and configuration files for visualising and interacting with the robot.
+
+### Setup Folder
+
+The offboard computer will need a copy of the [robot.yaml](../config/yaml/overview.mdx) file to generate the same `setup.bash`
+file as the robot.
+
+1. **Create the folder**
+
+For the offboard computer we can create the `clearpath` folder in the home directory:
+
+```
+mkdir ~/clearpath/
+```
+
+2. **Copy the `robot.yaml` file into the setup folder**
+
+```
+cp /path/to/robot.yaml ~/clearpath/
+```
+
+:::note
+If you have workspaces defined in the `robot.yaml` that do not exist on the offboard computer, remove them.
+:::
+
+3. **Generate the `setup.bash` file**
+
+```
+source /opt/ros/humble/setup.bash
+ros2 run clearpath_generator_common generate_bash -s ~/clearpath
+```
+
+Add the following line to your `~/.bashrc` file to automatically source the generated `setup.bash` file in new terminals:
+
+```
+source ~/clearpath/setup.bash
+```
+
+4. If you are using Fast DDS Discovery Server, follow the instructions on the [ROS 2 networking page](../networking/ros2-networking.mdx#offboard-pc).
\ No newline at end of file
diff --git a/docs/ros/installation/robot.mdx b/docs/ros/installation/robot.mdx
new file mode 100644
index 000000000..889bb1641
--- /dev/null
+++ b/docs/ros/installation/robot.mdx
@@ -0,0 +1,318 @@
+---
+title: Robot Installation
+sidebar_label: Robot
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import ClearpathFirmware from "../../components/_clearpath_firmware.mdx";
+import StandardClearpathBridgeSetup from "../../components/networking/_standard_clearpath_bridge_setup.mdx";
+import ComputerNetworkingSetupInstall from "../../components/networking/_computer_networking_setup_install.mdx";
+
+## Operating System (OS) {#operating-system}
+
+ROS 2 Humble uses Ubuntu 22.04 as its Tier 1 operating system.
+Though other operating systems are supported, it is highly recommended to use Ubuntu 22.04.
+The preferred method is using the Clearpath Robotics ISO image, which is covered in this section.
+
+:::note
+
+The Clearpath Robotics ISO image only targets x86 computers (`amd64` architecture).
+
+:::
+
+Clearpath provides a lightly customized installation image of Ubuntu 22.04 that has the needed script to setup the robot.
+To install the software on a physical robot through the Clearpath Robotics ISO image, you will first need a USB drive of at least 4 GB
+to create the installation media, an ethernet cable, a monitor, and a keyboard.
+
+1. Download the [ROS 2 Humble ISO image](https://packages.clearpathrobotics.com/stable/images/1.0.0/).
+
+2. Copy the image to a USB drive using `unetbootin`, `rufus`, `balena etcher`, or a similar program. For example:
+
+ ```
+ sudo unetbootin isofile="clearpath-jammy-humble-autoinstall.iso"
+ ```
+
+3. Connect your robot computer to internet access (via wired Ethernet), a keyboard, and a monitor.
+ Make sure that the robot is connected to shore power (where applicable) or that the robot's battery is fully charged.
+
+ :::caution
+
+ The next step wipes your robot's hard drive, so make sure you have that important data backed up.
+
+ :::
+
+4. Boot your robot computer from the USB drive and let the installer work its magic.
+
+ :::note
+
+ You may need to configure the computer's BIOS to prioritize booting from the USB drive.
+ On most common motherboards, pressing `Delete` during the initial startup will open the BIOS for configuration.
+
+ :::
+
+5. The setup process will be automated and may take a long time depending on the speed of your internet connection.
+6. Once the setup process is complete, the computer will turn off.
+ Please unplug the USB drive and turn the computer back on.
+7. On first boot, the username will be `administrator` and the password will be `clearpath`.
+ You should use the `passwd` utility to change the `administrator` account password.
+8. Log on to the computer and run `bash -e clearpath_computer_installer.sh` to install the needed software.
+ This will take a while to complete and has a prompts that must be answered.
+
+
+## Internet Connection
+
+### Wi-Fi
+
+To configure Wi-Fi, first log in to the robot's computer. This can be done by connecting the computer
+to a monitor using an HDMI or DisplayPort cable, and connecting a USB keyboard. Power the robot on and
+wait for the Ubuntu login prompt to show up.
+
+Once logged in, find the name of your Wi-Fi interface by calling `ip a`. Wi-Fi interface names begin with `wl`.
+
+
+
+
+
+
+
+Next, create the file `/etc/netplan/60-wireless.yaml`, and paste the following contents:
+
+```
+network:
+ wifis:
+ # Replace WIRELESS_INTERFACE with the name of the wireless network device, e.g. wlan0 or wlp3s0
+ # Fill in the SSID and PASSWORD fields as appropriate. The password may be included as plain-text
+ # or as a password hash. To generate the hashed password, run
+ # echo -n 'WIFI_PASSWORD' | iconv -t UTF-16LE | openssl md4 -binary | xxd -p
+ # If you have multiple wireless cards you may include a block for each device.
+ # For more options, see https://netplan.io/reference/
+ WIRELESS_INTERFACE:
+ optional: true
+ access-points:
+ SSID_GOES_HERE:
+ password: PASSWORD_GOES_HERE
+ dhcp4: true
+ dhcp4-overrides:
+ send-hostname: true
+```
+
+Replace `WIRELESS_INTERFACE` with the name of your Wi-Fi interface, `SSID_GOES_HERE` with your Wi-Fi
+SSID, and `PASSWORD_GOES_HERE` with your Wi-Fi password.
+
+Save the file and call `sudo netplan apply` to apply the changes. Check `ip a` again to make sure that
+an IP address has been assigned to your Wi-Fi interface.
+
+You should now be able to SSH into the robot by calling `ssh administrator@` from an offboard computer.
+
+:::note
+
+If the Wi-Fi interface indicates down (disabled), enable it using `sudo ip link set dev up`.
+Replace `` with the name of your disabled Wi-Fi interface.
+
+:::
+
+### Ethernet
+
+The robot's computer can also be connected to a DHCP network over Ethernet. Connect an Ethernet cable
+to the built-in Ethernet port on the robot's computer and check that an IP has been assigned with `ip a`.
+
+You should now be able to SSH into the robot by calling `ssh administrator@` from an offboard computer.
+
+## Firmware Update
+
+All platforms with the exception of the A200 will require a firmware update to run ROS 2 Humble.
+
+
+
+## Package Install
+
+### Option 1: Install Script
+
+#### Package Sourcing, and Install
+
+```
+wget -c https://raw.githubusercontent.com/clearpathrobotics/clearpath_computer_installer/main/clearpath_computer_installer.sh && bash -e clearpath_computer_installer.sh
+```
+
+#### Network Configuration
+
+
+
+For details on setting up custom network interface settings see [Clearpath Computer Setup](../networking/computer_setup.mdx).
+
+#### Robot YAML
+
+The `robot.yaml` file defines the configuration of the robot including the robot model, all
+supported accessories and any extra URDF elements or ROS parameters. Information about the Robot YAML
+is found in the [Robot Configuration](../config/yaml/overview.mdx) section. This YAML is used to generate the launch,
+URDF and ROS parameter files during runtime.
+
+Create your `robot.yaml` file and then copy it into `/etc/clearpath/` and replace the existing file.
+
+#### Start Service
+
+This script used [robot_upstart](https://github.com/clearpathrobotics/robot_upstart/tree/foxy-devel) to install the `systemd` services
+that will launch platform and sensor launch files as background processes.
+
+To start the services, call
+
+```
+sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
+```
+
+### Option 2: Manual Source Install
+
+
+ Click to expand the manual source install instructions. Only use this option if you
+ know what you are doing.
+
+
+ #### ROS 2 Humble
+
+ Follow the [official instructions](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html)
+ for installing ROS 2 Humble from debian packages.
+
+ #### Clearpath Package Server
+
+ The Clearpath package server needs to be added to the robot computer to access robot packages.
+
+ Configure Ubuntu's APT package manager to add the package server:
+
+ **1. Install the authentication key for the packages.clearpathrobotics.com repository**
+
+ ```
+ wget https://packages.clearpathrobotics.com/public.key -O - | sudo apt-key add -
+ ```
+
+ **2. Add the debian sources for the repository**
+
+ ```
+ sudo sh -c 'echo "deb https://packages.clearpathrobotics.com/stable/ubuntu $(lsb_release -cs) main" > /etc/apt/sources.list.d/clearpath-latest.list'
+ ```
+
+ **3. Update your computer’s package cache**
+
+ ```
+ sudo apt-get update
+ ```
+
+ #### Network Configuration
+
+
+
+ ##### Standard Clearpath Bridge
+
+
+
+ For details on setting up custom network interface settings see [Clearpath Computer Setup](../networking/computer_setup.mdx).
+
+ #### Clearpath Robot metapackage
+
+ Once the Clearpath package server has been added, the [Clearpath Robot](https://github.com/clearpathrobotics/clearpath_robot)
+ metapackage can be installed.
+
+ ```
+ sudo apt install ros-humble-clearpath-robot
+ ```
+
+ Installing this package will also install all dependencies required to run any Clearpath robot and supported sensors,
+ other than Clearpath firmware packages.
+
+ #### Source install
+
+ **1. Create a workspace on the robot's computer for the clearpath packages**
+
+ ```
+ mkdir ~/clearpath_ws/src -p
+ ```
+
+ **2. Import dependencies**
+
+ ```
+ source /opt/ros/humble/setup.bash
+ sudo apt install python3-vcstool
+ cd ~/clearpath_ws
+ wget https://raw.githubusercontent.com/clearpathrobotics/clearpath_robot/main/dependencies.repos
+ vcs import src < dependencies.repos
+ cd ~/clearpath_ws/src
+ git clone https://github.com/clearpathrobotics/clearpath_robot.git
+ cd ~/clearpath_ws
+ rosdep install -r --from-paths src -i -y
+ ```
+
+ **3. Build packages**
+
+ ```
+ colcon build --symlink-install
+ ```
+
+ **4. Link the workspace**
+
+ Add the following line to your `~/clearpath_ws/src/clearpath_robot/clearpath_robot/scripts/generate` file,
+ right under where ROS is sourced:
+
+ ```
+ source /home/administrator/clearpath_ws/install/setup.bash
+ ```
+
+
+ :::note
+
+ This workspace will also need to be sourced in your [robot.yaml](#robot-yaml) file as described
+ in the [ROS2 Environment](../config/yaml/system.mdx#ros-2-environment) section.
+
+ :::
+
+ #### Setup folder
+
+ Create the setup folder where the [robot.yaml](../config/yaml/overview.mdx) file will be stored, and where files will be generated:
+
+ ```
+ sudo mkdir /etc/clearpath/ -p && sudo chmod 777 /etc/clearpath/
+ ```
+ #### Robot YAML
+
+ The `robot.yaml` file defines the configuration of the robot including the robot model, all
+ supported accessories and any extra URDF elements or ROS parameters. Information about the Robot YAML
+ is found in the [Robot Configuration](../config/yaml/overview.mdx) section. This YAML is used to generate the launch,
+ URDF and ROS parameter files during runtime.
+
+ Create your `robot.yaml` file and then copy it into `/etc/clearpath/`.
+
+ #### Robot services
+
+ Clearpath robot services can now be installed with the following command:
+
+ ```
+ source /opt/ros/humble/setup.bash
+ ros2 run clearpath_robot install
+ sudo systemctl enable clearpath-robot
+ ```
+
+ This script uses [robot_upstart](https://github.com/clearpathrobotics/robot_upstart/tree/foxy-devel) to install the `systemd` services
+ that will launch platform and sensor launch files as background processes.
+
+ To start the services, call
+
+ ```
+ sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
+ ```
+
+ Add the following line to your `~/.bashrc` file to automatically source the generated `setup.bash` file in new terminals:
+
+ ```
+ source /etc/clearpath/setup.bash
+ ```
+
+ #### Additional settings
+
+ Certain sensors may require additional setup, please review the [Accessories](../../robots/accessories/accessories.mdx) pages
+ for any additional instructions for the sensors that you are using. For example, the Blackfly camera has additional instructions
+ listed under [software bringup](../../robots/accessories/sensors/cameras/flir_blackfly_s#software-bringup).
+
+
diff --git a/docs/ros/installation/upgrading.mdx b/docs/ros/installation/upgrading.mdx
new file mode 100644
index 000000000..8f82cc927
--- /dev/null
+++ b/docs/ros/installation/upgrading.mdx
@@ -0,0 +1,723 @@
+---
+title: Upgrading to Humble
+sidebar_label: Upgrading to Humble
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+:::note
+
+Users who are installing ROS 2 Humble onto a new robot computer can skip to [Robot Installation](robot.mdx).
+
+:::
+
+:::note
+
+Check the [list of supported platforms](../../ros/ros.mdx#supported-platforms) to make sure that your robot is currently
+supported on ROS 2 Humble.
+
+:::
+
+ROS 2 Humble is the first ROS distribution that runs on Ubuntu 22.04. As a result, any robots running ROS 1 or
+ROS 2 Foxy will have upgrade their operating system. It is highly recommended to back up any important files on the robot
+before proceeding, especially for highly customized robots.
+
+:::caution
+
+It is the user’s responsibility to ensure that any essential files are properly backed-up before upgrading their robot.
+
+:::
+
+## Saving a hard drive image
+
+As a fail-safe, please make an image of your robot's hard drive. You should always be able to restore this
+image if you need to revert back to your previous configuration. The easiest approach may be to either connect
+a removable (USB or similar) hard drive to the robot's computer, or to unplug the robot's hard drive and insert
+it into a computer or workstation. You can then use a tool such as [CloneZilla](https://clonezilla.org/) or `dd`
+to write a backup image of your robot's hard drive onto another hard drive. Alternatively, you can simply replace
+the robot computer's hard drive, reserving the drive and installing a new one to use with Humble.
+
+## Saving important files
+
+There are several places in the filesystem you should specifically look for customizations for your robot:
+
+| **Location** | **Description** |
+| :-------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/etc/network/interfaces` or `/etc/netplan/*` | Your robot may have a custom network configuration in this file. |
+| `/etc/ros/*/*-core.d/*.launch` | Will contain `base.launch` and `description.launch`, may contain custom launch files for your robot configuration. Replaced by `ros.d` in newer versions. |
+| `/etc/ros/*/ros.d/*.launch ` | Will contain `base.launch` and `description.launch`, may contain custom launch files for your robot configuration. Replaces `*-core.d` in newer versions. |
+| `/etc/ros/setup.bash` | May contain environment variables for your configuration. |
+| `~/catkin_ws/` or `~/colcon_ws/` | ROS workspace that may contain custom ROS packages. |
+
+Please save the files listed above and use them as a reference during Humble configuration.
+
+## Backup Software (ROS 1 only)
+
+Clearpath Robotics provides a package containing several shell scripts to help you back up, upgrade, and/or
+restore your ROS 1 robot’s important data. You can use these scripts by downloading the `robot-backup` repository
+by running the following command on your computer:
+
+```
+git clone https://github.com/clearpathrobotics/robot-backup
+```
+
+You will need to install dependencies to be able to use these scripts. The instructions for installing dependencies
+can be found in the `README.md` file of the repository, or run the following command on your computer:
+
+```
+sudo apt-get install sshpass sudo apt-get install rsync
+```
+
+### Running the backup script
+
+Ensure that the robot is turned on and that you can SSH into it from your computer. Then run the following from your computer:
+
+```
+cd robot-backup
+bash backup.sh
+```
+
+For example, if your robot’s IP address is 192.168.1.103, you would run something like:
+
+```
+bash backup.sh melodic-final-backup 192.168.1.103
+```
+
+This will produce a backup file called `melodic-final-backup.tar.gz`. Keep this file for when you need to access your backed-up data.
+
+By default all Clearpath robots use the username `administrator` and the password `clearpath`. The backup.sh
+script will use these credentials by default, but you can override them easily.
+
+For example, if your robot’s username and password have been set to `my_robot_username` and `my_robot_password` you should run:
+
+```
+bash backup.sh melodic-final-backup my_robot_username@192.168.1.103 my_robot_password
+```
+
+### Backed up contents
+
+The backup script will copy the following data:
+
+- Home Folder: `~/`
+- `udev` Rules: `/etc/udev/rules.d`
+- Network Setup: - `/etc/network/interfaces` - `/etc/netplan` - `/etc/hostname` - `/etc/hosts`
+- IP Tables: `/etc/iptables`
+- Bringup Files: - `/etc/ros/setup.bash` - `/etc/ros/$ROSDISTRO/ros.d` - `/usr/sbin/*start` - `/usr/sbin/*stop`
+- `rosdep` sources: `/etc/ros/rosdep`
+- `rc.local` File: `/etc/rc.local`
+- `pip` packages
+- `systemd` configuration: `/etc/systemd/system`
+- `apt` sources: `/etc/apt/sources.list.d`
+- `apt` packages
+- User Permission Groups
+
+### Backing up non-standard data
+
+The `backup.sh` script assumes that your robot is in a roughly-standard configuration; it uses a single user
+account and no files within `/opt/ros/$ROS_DISTRO`have been modified.
+
+If this is not the case, it is the responsibility of the user to ensure that any modified files and files in
+other users’ home folders is backed up correctly.
+
+A common example of this might be if you have created customized URDF files to be loaded via environment
+variables (such as, `JACKAL_URDF_EXTRAS` for the Jackal) and have stored them outside any of the folders specified above, you must
+back these up yourself; `backup.sh` will not do this for you.
+
+## Converting Environment Variables to Clearpath Config
+
+The environment variables used to define your robot in ROS 1 and ROS 2 Foxy can be converted to the `robot.yaml`
+format to maintain the same robot description when you upgrade to ROS 2 Humble.
+Below are some common examples. Visit the [robot.yaml documentation](../config/yaml/overview.mdx) for more details.
+
+### Attachments
+
+Each platform has platform-specific attachments (formerly decorations) such as bumpers and top plates. These
+now reside under the [platform](../config/yaml/platform/attachments/overview.mdx) section of the `robot.yaml` file.
+
+
+
+
+Environment variables:
+
+```
+export HUSKY_FRONT_BUMPER=1
+export HUSKY_REAR_BUMPER=1
+export HUSKY_FRONT_BUMPER_EXTEND=0
+export HUSKY_REAR_BUMPER_EXTEND=0.1
+export HUSKY_TOP_PLATE_ENABLED=1
+export HUSKY_LARGE_TOP_PLATE=1
+export HUSKY_USER_RAIL_ENABLED=0
+export HUSKY_SENSOR_ARCH=1
+export HUSKY_SENSOR_ARCH_HEIGHT='510'
+export HUSKY_SENSOR_ARCH_OFFSET='0 0 0'
+export HUSKY_SENSOR_ARCH_RPY='0 0 0'
+```
+
+`robot.yaml` configuration:
+
+```
+platform:
+ attachments:
+ - name: front_bumper
+ type: a200.bumper
+ model: default
+ parent: front_bumper_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true # HUSKY_FRONT_BUMPER=1
+ extension: 0.0 # HUSKY_FRONT_BUMPER_EXTEND=0
+ - name: rear_bumper
+ type: a200.bumper
+ model: default
+ parent: rear_bumper_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true # HUSKY_REAR_BUMPER=1
+ extension: 0.1 # HUSKY_REAR_BUMPER_EXTEND=0.1
+ - name: top_plate
+ type: a200.top_plate
+ model: large # HUSKY_LARGE_TOP_PLATE=1
+ parent: mid_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true # HUSKY_TOP_PLATE_ENABLED=1
+ - name: sensor_arch
+ type: a200.sensor_arch
+ model: sensor_arch_300 # HUSKY_SENSOR_ARCH_HEIGHT='510'
+ parent: mid_mount
+ xyz: [0.0, 0.0, 0.0] # HUSKY_SENSOR_ARCH_OFFSET='0 0 0'
+ rpy: [0.0, 0.0, 0.0] # HUSKY_SENSOR_ARCH_RPY='0 0 0'
+ enabled: true
+```
+
+
+
+Environment variables:
+
+```
+export JACKAL_FRONT_ACCESSORY_FENDER=1
+export JACKAL_REAR_ACCESSORY_FENDER=0
+```
+
+`robot.yaml` configuration:
+
+```
+platform:
+ attachments:
+ - name: front_fender
+ type: fender
+ model: default
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true # JACKAL_FRONT_ACCESSORY_FENDER=1
+ - name: rear_fender
+ type: fender
+ model: default
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 3.1415]
+ enabled: false # JACKAL_REAR_ACCESSORY_FENDER=0
+```
+
+
+
+
+### Sensors
+
+Sensors can be added under the [sensors](../config/yaml/sensors/overview.mdx) key in the `robot.yaml` file. There is no longer
+a concept of primary, secondary, etc. sensors. Rather, sensors are enumerated in the order that they are added to the config.
+Sensor topics will be automatically set to match the [Clearpath API](../api/sensors_api.mdx#2d-lidar-topics).
+
+
+#### 2D Lidar
+
+
+
+
+Environment variables:
+
+```
+# Primary Laser
+export HUSKY_LMS1XX_ENABLED=1
+export HUSKY_LMS1XX_TOPIC='front/scan'
+export HUSKY_LMS1XX_IP='192.168.131.20'
+export HUSKY_LMS1XX_PREFIX='front'
+export HUSKY_LMS1XX_PARENT='top_plate_link'
+export HUSKY_LMS1XX_XYZ='0.2206 0.0 0.00635'
+export HUSKY_LMS1XX_RPY='0.0 0.0 0.0'
+
+# Secondary Laser
+export HUSKY_LMS1XX_SECONDARY_ENABLED=1
+export HUSKY_LMS1XX_SECONDARY_TOPIC='rear/scan'
+export HUSKy_LMS1XX_SECONDARY_IP='192.168.131.21'
+export HUSKY_LMS1XX_SECONDARY_PREFIX='rear'
+export HUSKY_LMS1XX_SECONDARY_PARENT='top_plate_link'
+export HUSKY_LMS1XX_SECONDARY_XYZ='-0.2206 0.0 0.00635'
+export HUSKY_LMS1XX_SECONDARY_RPY='0.0 0.0 3.14159'
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ lidar2d:
+ - model: sick_lms1xx # HUSKY_LMS1XX_ENABLED=1
+ urdf_enabled: true
+ launch_enabled: true
+ parent: top_plate_link # HUSKY_LMS1XX_PARENT='top_plate_link'
+ xyz: [0.2206, 0.0, 0.00635] # HUSKY_LMS1XX_XYZ='0.2206 0.0 0.00635'
+ rpy: [0.0, 0.0, 0.0] # HUSKY_LMS1XX_RPY='0.0 0.0 0.0'
+ ros_parameters:
+ lms1xx:
+ frame_id: lidar2d_0_laser
+ hostname: 192.168.131.20 # HUSKY_LMS1XX_IP='192.168.131.20'
+ port: 2112
+ min_ang: -2.391
+ max_ang: 2.391
+ - model: sick_lms1xx # HUSKY_LMS1XX_SECONDARY_ENABLED=1
+ urdf_enabled: true
+ launch_enabled: true
+ parent: top_plate_link # HUSKY_LMS1XX_SECONDARY_PARENT='top_plate_link'
+ xyz: [-0.2206, 0.0, 0.00635] # HUSKY_LMS1XX_SECONDARY_XYZ='-0.2206 0.0 0.00635'
+ rpy: [0.0, 0.0, 3.14159] # HUSKY_LMS1XX_SECONDARY_RPY='0.0 0.0 3.14159'
+ ros_parameters:
+ lms1xx:
+ frame_id: lidar2d_1_laser
+ hostname: 192.168.131.21 # HUSKy_LMS1XX_SECONDARY_IP='192.168.131.21'
+ port: 2112
+ min_ang: -2.391
+ max_ang: 2.391
+```
+
+
+
+Environment variables:
+
+```
+# Primary Laser
+export JACKAL_LASER=1
+export JACKAL_LASER_MODEL=lms1xx
+export JACKAL_LASER_TOPIC="front/scan"
+export JACKAL_LASER_HOST="192.168.131.20"
+export JACKAL_LASER_MOUNT="front"
+export JACKAL_LASER_PREFIX="front"
+export JACKAL_LASER_PARENT="front_mount"
+export JACKAL_LASER_OFFSET="0 0 0"
+export JACKAL_LASER_RPY="0 0 0"
+
+# Secondary Laser
+export JACKAL_LASER_SECONDARY=1
+export JACKAL_LASER_SECONDARY_MODEL="lms1xx"
+export JACKAL_LASER_SECONDARY_HOST="192.168.131.21"
+export JACKAL_LASER_SECONDARY_TOPIC="rear/scan"
+export JACKAL_LASER_SECONDARY_MOUNT="rear"
+export JACKAL_LASER_SECONDARY_PREFIX="rear"
+export JACKAL_LASER_SECONDARY_PARENT="rear_mount"
+export JACKAL_LASER_SECONDARY_OFFSET="0 0 0"
+export JACKAL_LASER_SECONDARY_RPY="0 0 3.14159"
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ lidar2d:
+ - model: sick_lms1xx # JACKAL_LASER_MODEL=lms1xx
+ urdf_enabled: true
+ launch_enabled: true # JACKAL_LASER=1
+ parent: front_mount # JACKAL_LASER_PARENT="front_mount"
+ xyz: [0.0, 0.0, 0.0] # JACKAL_LASER_OFFSET="0 0 0"
+ rpy: [0.0, 0.0, 0.0] # JACKAL_LASER_RPY="0 0 0"
+ ros_parameters:
+ lms1xx:
+ frame_id: lidar2d_0_laser
+ hostname: 192.168.131.20 # JACKAL_LASER_HOST="192.168.131.20"
+ port: 2112
+ min_ang: -2.391
+ max_ang: 2.391
+ - model: sick_lms1xx # JACKAL_LASER_SECONDARY_MODEL="lms1xx"
+ urdf_enabled: true
+ launch_enabled: true # JACKAL_LASER_SECONDARY=1
+ parent: rear_mount # JACKAL_LASER_SECONDARY_PARENT="rear_mount"
+ xyz: [0.0, 0.0, 0.0] # JACKAL_LASER_SECONDARY_OFFSET="0 0 0"
+ rpy: [0.0, 0.0, 3.14159] # JACKAL_LASER_SECONDARY_RPY="0 0 3.14159"
+ ros_parameters:
+ lms1xx:
+ frame_id: lidar2d_1_laser
+ hostname: 192.168.131.21 # JACKAL_LASER_SECONDARY_HOST="192.168.131.21"
+ port: 2112
+ min_ang: -2.391
+ max_ang: 2.391
+```
+
+
+
+#### 3D Lidar
+
+
+
+
+Environment variables:
+
+```
+# Primary Laser
+export HUSKY_LASER_3D_ENABLED=1
+export HUSKY_LASER_3D_TOPIC='points'
+export HUSKY_LASER_3D_HOST='192.168.131.20'
+export HUSKY_LASER_3D_TOWER=1
+export HUSKY_LASER_3D_PREFIX=''
+export HUSKY_LASER_3D_PARENT='top_plate_link'
+export HUSKY_LASER_3D_XYZ='0.2206 0.0 0.00635'
+export HUSKY_LASER_3D_RPY='0 0 0'
+
+# Secondary Laser
+export HUSKY_LASER_3D_SECONDARY_ENABLED=1
+export HUSKY_LASER_3D_SECONDARY_HOST='192.168.131.21'
+export HUSKY_LASER_3D_SECONDARY_TOPIC='secondary_points'
+export HUSKY_LASER_3D_SECONDARY_TOWER=1
+export HUSKY_LASER_3D_SECONDARY_PREFIX='secondary_'
+export HUSKY_LASER_3D_SECONDARY_PARENT='top_plate_link'
+export HUSKY_LASER_3D_SECONDARY_XYZ='-0.2206 0.0 0.00635'
+export HUSKY_LASER_3D_SECONDARY_RPY='0 0 3.14159'
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ lidar3d:
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true # HUSKY_LASER_3D_ENABLED=1
+ parent: top_plate_link # HUSKY_LASER_3D_PARENT='top_plate_link'
+ xyz: [0.2206, 0.0, 0.00635] # HUSKY_LASER_3D_XYZ='0.2206 0.0 0.00635'
+ rpy: [0.0, 0.0, 0.0] # HUSKY_LASER_3D_RPY='0 0 0'
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.20 # HUSKY_LASER_3D_HOST='192.168.131.20'
+ port: 2368
+ model: VLP16
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true # HUSKY_LASER_3D_SECONDARY_ENABLED=1
+ parent: top_plate_link # HUSKY_LASER_3D_SECONDARY_PARENT='top_plate_link'
+ xyz: [-0.2206, 0.0, 0.00635] # HUSKY_LASER_3D_SECONDARY_XYZ='-0.2206 0.0 0.00635'
+ rpy: [0.0, 0.0, 3.14159] # HUSKY_LASER_3D_SECONDARY_RPY='0 0 3.14159'
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_1_laser
+ device_ip: 192.168.131.21 # HUSKY_LASER_3D_SECONDARY_HOST='192.168.131.21'
+ port: 2368
+ model: VLP16
+```
+
+
+
+Environment variables:
+
+```
+export JACKAL_LASER_3D=1
+export JACKAL_LASER_3D_HOST="192.168.131.20"
+export JACKAL_LASER_3D_TOPIC="mid/points"
+export JACKAL_LASER_3D_TOWER=1
+export JACKAL_LASER_3D_MOUNT="mid"
+export JACKAL_LASER_3D_PREFIX="mid"
+export JACKAL_LASER_3D_PARENT="mid_mount"
+export JACKAL_LASER_3D_MODEL="vlp16"
+export JACKAL_LASER_3D_OFFSET="0 0 0"
+export JACKAL_LASER_3D_RPY="0 0 0"
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ lidar3d:
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true # JACKAL_LASER_3D=1
+ parent: mid_mount # JACKAL_LASER_3D_PARENT="mid_mount"
+ xyz: [0.0, 0.0, 0.0] # JACKAL_LASER_3D_OFFSET="0 0 0"
+ rpy: [0.0, 0.0, 0.0] # JACKAL_LASER_3D_RPY="0 0 0"
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.20 # JACKAL_LASER_3D_HOST="192.168.131.20"
+ port: 2368
+ model: VLP16
+```
+
+
+
+#### Camera
+
+
+
+
+Environment variables:
+
+```
+# Primary Camera
+export HUSKY_REALSENSE_ENABLED=1
+export HUSKY_REALSENSE_SERIAL='0'
+export HUSKY_REALSENSE_TOPIC='realsense'
+export HUSKY_REALSENSE_POINTCLOUD_ENABLED=1
+export HUSKY_REALSENSE_DEPTH_ENABLED=1
+export HUSKY_REALSENSE_DEPTH_FRAMERATE='30'
+export HUSKY_REALSENSE_DEPTH_HEIGHT='480'
+export HUSKY_REALSENSE_DEPTH_WIDTH='640'
+export HUSKY_REALSENSE_COLOR_ENABLED=1
+export HUSKY_REALSENSE_COLOR_FRAMERATE='30'
+export HUSKY_REALSENSE_COLOR_HEIGHT='480'
+export HUSKY_REALSENSE_COLOR_WIDTH='640'
+export HUSKY_REALSENSE_PREFIX='camera'
+export HUSKY_REALSENSE_PARENT='top_plate_link'
+export HUSKY_REALSENSE_XYZ='0 0 0'
+export HUSKY_REALSENSE_RPY='0 0 0'
+
+# Secondary Camera
+export HUSKY_REALSENSE_SECONDARY_ENABLED=1
+export HUSKY_REALSENSE_SECONDARY_SERIAL='1'
+export HUSKY_REALSENSE_SECONDARY_TOPIC='realsense_secondary'
+export HUSKY_REALSENSE_SECONDARY_POINTCLOUD_ENABLED=1
+export HUSKY_REALSENSE_SECONDARY_DEPTH_ENABLED=1
+export HUSKY_REALSENSE_SECONDARY_DEPTH_FRAMERATE='30'
+export HUSKY_REALSENSE_SECONDARY_DEPTH_HEIGHT='480'
+export HUSKY_REALSENSE_SECONDARY_DEPTH_WIDTH='640'
+export HUSKY_REALSENSE_SECONDARY_COLOR_ENABLED=1
+export HUSKY_REALSENSE_SECONDARY_COLOR_FRAMERATE='30'
+export HUSKY_REALSENSE_SECONDARY_COLOR_HEIGHT='480'
+export HUSKY_REALSENSE_SECONDARY_COLOR_WIDTH='640'
+export HUSKY_REALSENSE_SECONDARY_PREFIX='secondary_camera'
+export HUSKY_REALSENSE_SECONDARY_PARENT='top_plate_link'
+export HUSKY_REALSENSE_SECONDARY_XYZ='0 0 0'
+export HUSKY_REALSENSE_SECONDARY_RPY='0 0 0'
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ camera:
+ - model: intel_realsense
+ urdf_enabled: true
+ launch_enabled: true # HUSKY_REALSENSE_ENABLED=1
+ parent: top_plate_link # HUSKY_REALSENSE_PARENT='top_plate_link'
+ xyz: [0.0, 0.0, 0.0] # HUSKY_REALSENSE_XYZ='0 0 0'
+ rpy: [0.0, 0.0, 0.0] # HUSKY_REALSENSE_RPY='0 0 0'
+ ros_parameters:
+ intel_realsense:
+ camera_name: camera_0
+ device_type: d435
+ serial_no: "0" # HUSKY_REALSENSE_SERIAL='0'
+ enable_color: true # HUSKY_REALSENSE_COLOR_ENABLED=1
+ rgb_camera.profile: 640,480,30 # HUSKY_REALSENSE_COLOR_WIDTH='640'
+ # HUSKY_REALSENSE_COLOR_HEIGHT='480'
+ # HUSKY_REALSENSE_COLOR_FRAMERATE='30'
+ enable_depth: true # HUSKY_REALSENSE_DEPTH_ENABLED=1
+ depth_module.profile: 640,480,30 # HUSKY_REALSENSE_DEPTH_WIDTH='640'
+ # HUSKY_REALSENSE_DEPTH_HEIGHT='480'
+ # HUSKY_REALSENSE_DEPTH_FRAMERATE='30'
+ pointcloud.enable: true # HUSKY_REALSENSE_POINTCLOUD_ENABLED=1
+ - model: intel_realsense
+ urdf_enabled: true
+ launch_enabled: true # HUSKY_REALSENSE_SECONDARY_ENABLED=1
+ parent: top_plate_link # HUSKY_REALSENSE_SECONDARY_PARENT='top_plate_link'
+ xyz: [0.0, 0.0, 0.0] # HUSKY_REALSENSE_SECONDARY_XYZ='0 0 0'
+ rpy: [0.0, 0.0, 0.0] # HUSKY_REALSENSE_SECONDARY_RPY='0 0 0'
+ ros_parameters:
+ intel_realsense:
+ camera_name: camera_1
+ device_type: d435
+ serial_no: "1" # HUSKY_REALSENSE_SECONDARY_SERIAL='1'
+ enable_color: true # HUSKY_REALSENSE_SECONDARY_COLOR_ENABLED=1
+ rgb_camera.profile: 640,480,30 # HUSKY_REALSENSE_SECONDARY_COLOR_WIDTH='640'
+ # HUSKY_REALSENSE_SECONDARY_COLOR_HEIGHT='480'
+ # HUSKY_REALSENSE_SECONDARY_COLOR_FRAMERATE='30'
+ enable_depth: true # HUSKY_REALSENSE_SECONDARY_DEPTH_ENABLED=1
+ depth_module.profile: 640,480,30 # HUSKY_REALSENSE_SECONDARY_DEPTH_WIDTH='640'
+ # HUSKY_REALSENSE_SECONDARY_DEPTH_HEIGHT='480'
+ # HUSKY_REALSENSE_SECONDARY_DEPTH_FRAMERATE='30'
+ pointcloud.enable: true # HUSKY_REALSENSE_SECONDARY_POINTCLOUD_ENABLED=1
+```
+
+
+
+#### IMU
+
+
+
+
+Environment variables:
+
+```
+export HUSKY_IMU_XYZ='0.19 0 0.149'
+export HUSKY_IMU_RPY='0 -1.5708 3.1416'
+export HUSKY_IMU_PARENT='base_link'
+export HUSKY_IMU_PORT='/dev/microstrain'
+export HUSKY_MAG_CONFIG="$(catkin_find 'husky_bringup' --first-only)/config/mag_config_default.yaml"
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ imu:
+ - model: microstrain_imu
+ urdf_enabled: true
+ launch_enabled: true
+ parent: base_link # HUSKY_IMU_PARENT='base_link'
+ xyz: [0.19, 0.0, 0.149] # HUSKY_IMU_XYZ='0.19 0 0.149'
+ rpy: [0, -1.5708, 3.1416] # HUSKY_IMU_RPY='0 -1.5708 3.1416'
+ ros_parameters:
+ imu_frame_id: imu_0_link
+ port: /dev/microstrain # HUSKY_IMU_PORT='/dev/microstrain'
+ use_enu_frame: true
+```
+
+
+
+Environment variables:
+
+```
+export JACKAL_IMU_MICROSTRAIN=1
+export JACKAL_IMU_MICROSTRAIN_NAME="microstrain"
+export JACKAL_IMU_MICROSTRAIN_LINK="microstrain_link"
+export JACKAL_IMU_MICROSTRAIN_PARENT="base_link"
+export JACKAL_IMU_MICROSTRAIN_OFFSET="-0.139 0.096 0.100"
+export JACKAL_IMU_MICROSTRAIN_RPY="3.14159 0 -1.5707"
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ imu:
+ - model: microstrain_imu # JACKAL_IMU_MICROSTRAIN=1
+ urdf_enabled: true
+ launch_enabled: true
+ parent: base_link # JACKAL_IMU_MICROSTRAIN_PARENT="base_link"
+ xyz: [-0.139, 0.096, 0.100] # JACKAL_IMU_MICROSTRAIN_OFFSET="-0.139 0.096 0.100"
+ rpy: [3.14159, 0.0, -1.5707] # JACKAL_IMU_MICROSTRAIN_RPY="3.14159 0 -1.5707"
+ ros_parameters:
+ imu_frame_id: imu_0_link
+ port: /dev/microstrain
+ use_enu_frame: true
+```
+
+
+
+#### GPS
+
+
+
+
+Environment variables:
+
+```
+export HUSKY_NAVSAT_PORT=/dev/clearpath/gps
+export HUSKY_NAVSAT_BAUD=19200
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ gps:
+ - model: novatel_smart6
+ urdf_enabled: true
+ launch_enabled: true
+ parent: top_plate_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ nmea_navsat_driver:
+ port:"/dev/clearpath/gps" # HUSKY_NAVSAT_PORT=/dev/clearpath/gps
+ baud: 19200 # HUSKY_NAVSAT_BAUD=19200
+```
+
+
+
+Environment variables:
+
+```
+export JACKAL_NAVSAT=1
+export JACKAL_NAVSAT_PORT="/dev/clearpath/gps"
+export JACKAL_NAVSAT_BAUD=57600
+export JACKAL_NAVSAT_RTK=0
+export JACKAL_NAVSAT_RTK_DEVICE=wlan0
+export JACKAL_NAVSAT_RTK_BAUD=57600
+export JACKAL_NAVSAT_MOUNT="rear"
+export JACKAL_NAVSAT_PREFIX="rear"
+export JACKAL_NAVSAT_PARENT="rear_mount"
+export JACKAL_NAVSAT_MODEL="smart6"
+export JACKAL_NAVSAT_OFFSET="0 0 0"
+export JACKAL_NAVSAT_RPY="0 0 0"
+```
+
+`robot.yaml` configuration:
+
+```
+sensors:
+ gps:
+ - model: novatel_smart6 # JACKAL_NAVSAT_MODEL="smart6"
+ urdf_enabled: true
+ launch_enabled: true # JACKAL_NAVSAT=1
+ parent: rear_mount # JACKAL_NAVSAT_PARENT="rear_mount"
+ xyz: [0.0, 0.0, 0.0] # JACKAL_NAVSAT_OFFSET="0 0 0"
+ rpy: [0.0, 0.0, 0.0] # JACKAL_NAVSAT_RPY="0 0 0"
+ ros_parameters:
+ nmea_navsat_driver:
+ port:"/dev/clearpath/gps" # JACKAL_NAVSAT_PORT="/dev/clearpath/gps"
+ baud: 57600 # JACKAL_NAVSAT_BAUD=57600
+```
+
+
+
+## Next steps
+Once everything is backed up and you have created your robot.yaml file, the next step is to go through
+the [robot install instructions](robot.mdx). This will involve installing the new OS.
diff --git a/docs/ros/networking/_category_.json b/docs/ros/networking/_category_.json
new file mode 100644
index 000000000..fe62884e9
--- /dev/null
+++ b/docs/ros/networking/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Networking",
+ "position": 5
+}
diff --git a/docs/ros/networking/computer_setup.mdx b/docs/ros/networking/computer_setup.mdx
new file mode 100644
index 000000000..6c147ba5d
--- /dev/null
+++ b/docs/ros/networking/computer_setup.mdx
@@ -0,0 +1,29 @@
+---
+title: Clearpath Computer Setup
+sidebar_position: 2
+---
+import ComputerNetworkingSetupInstall from "../../components/networking/_computer_networking_setup_install.mdx";
+import StandardClearpathBridgeSetup from "../../components/networking/_standard_clearpath_bridge_setup.mdx";
+
+
+
+### Standard Clearpath Bridge
+
+
+
+### Custom Networking
+
+The `clearpath-computer-setup` tool can also be used to set up custom network interfaces.
+
+1. Navigate to the **Netplan Setup** menu and use the bridge, Ethernet, or Wi-Fi setup menus to add configurations.
+2. Once you are done configuring, return to the **Netplan Setup** menu and select **Write Configuration YAML**. You will be prompted for a file name. The file should be
+placed under `/etc/netplan/` to take effect, and the naming convention is a two digit number followed by a unique name.
+For example, `/etc/netplan/50-home-wifi.yaml`.
+
+:::note
+
+Netplan will read files under `/etc/netplan/` in alphanumeric order. Files beginning in `01` will be read first, and `99` will be read last.
+If two files define the same configuration, the configuration read last will be used. Otherwise, netplan will
+amalgamate all files under `/etc/netplan/` to create the netplan configuration.
+
+:::
diff --git a/docs/ros/networking/img/network-integrity-troubleshooting-flowchart.png b/docs/ros/networking/img/network-integrity-troubleshooting-flowchart.png
new file mode 100644
index 000000000..672aed012
Binary files /dev/null and b/docs/ros/networking/img/network-integrity-troubleshooting-flowchart.png differ
diff --git a/docs/ros/networking/img/ros2-comms-troubleshooting-flowchart.png b/docs/ros/networking/img/ros2-comms-troubleshooting-flowchart.png
new file mode 100644
index 000000000..c6a3f478b
Binary files /dev/null and b/docs/ros/networking/img/ros2-comms-troubleshooting-flowchart.png differ
diff --git a/docs/ros/networking/img/ros2-fastdds-command-center-diagram.png b/docs/ros/networking/img/ros2-fastdds-command-center-diagram.png
new file mode 100644
index 000000000..82b2e3582
Binary files /dev/null and b/docs/ros/networking/img/ros2-fastdds-command-center-diagram.png differ
diff --git a/docs/ros/networking/img/ros2-fastdds-discovery-server-diagram.png b/docs/ros/networking/img/ros2-fastdds-discovery-server-diagram.png
new file mode 100644
index 000000000..44a550977
Binary files /dev/null and b/docs/ros/networking/img/ros2-fastdds-discovery-server-diagram.png differ
diff --git a/docs/ros/networking/img/ros2-fastdds-fully-connected-diagram.png b/docs/ros/networking/img/ros2-fastdds-fully-connected-diagram.png
new file mode 100644
index 000000000..2e6c88ac1
Binary files /dev/null and b/docs/ros/networking/img/ros2-fastdds-fully-connected-diagram.png differ
diff --git a/docs/ros/networking/img/ros2-fastdds-simple-discovery-diagram.png b/docs/ros/networking/img/ros2-fastdds-simple-discovery-diagram.png
new file mode 100644
index 000000000..cb6b2c292
Binary files /dev/null and b/docs/ros/networking/img/ros2-fastdds-simple-discovery-diagram.png differ
diff --git a/docs/ros/networking/network_ip_addresses.mdx b/docs/ros/networking/network_ip_addresses.mdx
new file mode 100644
index 000000000..0292a290d
--- /dev/null
+++ b/docs/ros/networking/network_ip_addresses.mdx
@@ -0,0 +1,68 @@
+---
+title: Network IP Addresses
+sidebar_position: 4
+---
+
+These are the standard addresses that Clearpath uses for custom robot configurations.
+The details of your specific integration should have been included with your robot as a _robosmiths memo_
+stating the device, serial number, and IP address.
+
+This chart is for reference, to help you decide what address to assign sensors or computers that you are adding to a robot.
+
+| Device Family | Device Description | Static IP Address/Range | Comments |
+| :--------------- | :---------------------- | :---------------------- | :------------------------------------- |
+| Computers & MCUs | Primary Computer | 192.168.131.1 | The `roscore` process always runs here |
+| | MCU | 192.168.131.2 | Used on Dingo, Ridgeback, Warthog |
+| | | 192.168.131.3 | |
+| | | 192.168.131.4 | |
+| | Secondary Computer | 192.168.131.5 | |
+| | Tertiary Computer | 192.168.131.6 | |
+| | | 192.168.131.8 | |
+| | | 192.168.131.8 | |
+| | | 192.168.131.9 | |
+| Cameras & Vision | Primary/front camera | 192.168.131.10 | |
+| | Secondary/rear camera | 192.168.131.11 | |
+| | | 192.168.131.12 | |
+| | | 192.168.131.13 | |
+| | | 192.168.131.14 | |
+| | | 192.168.131.15 | |
+| | | 192.168.131.15 | |
+| | | 192.168.131.17 | |
+| | | 192.168.131.18 | |
+| | | 192.168.131.19 | |
+| 2D & 3D Lidar | Primary/front lidar | 192.168.131.20 | |
+| | Secondary/rear lidar | 192.168.131.21 | |
+| | Tertiary lidar | 192.168.131.22 | |
+| | | 192.168.131.23 | |
+| | | 192.168.131.24 | |
+| | | 192.168.131.25 | |
+| | | 192.168.131.26 | |
+| | | 192.168.131.27 | |
+| | | 192.168.131.28 | |
+| | | 192.168.131.29 | |
+| GPS | GPS (base station) | 192.168.131.30 | |
+| | GPS (primary/position) | 192.168.131.31 | |
+| | GPS (secondary/heading) | 192.168.131.32 | |
+| | | 192.168.131.33 | |
+| | | 192.168.131.34 | |
+| Sonar | Primary sonar | 192.168.131.35 | |
+| | Secondary sonar | 192.168.131.36 | |
+| | | 192.168.131.37 | |
+| | | 192.168.131.38 | |
+| | | 192.168.131.39 | |
+| Arms | Primary/left arm | 192.168.131.40 | |
+| | Secondary/right arm | 192.168.131.41 | |
+| | | 192.168.131.42 | |
+| | | 192.168.131.43 | |
+| | | 192.168.131.44 | |
+| Grippers | Primary/left hand | 192.168.131.45 | |
+| | Secondary/right hand | 192.168.131.46 | |
+| | | 192.168.131.47 | |
+| | | 192.168.131.48 | |
+| | | 192.168.131.49 | |
+| | Radio (base station) | 192.168.131.50 | |
+| | Radio (internal) | 192.168.131.51 | |
+| Networking HW | Additional radios | 192.168.131.52 - 69 | |
+| Unassigned | | 192.168.131.70 - 99 | Available as overflow for other ranges |
+| DHCP | | 192.168.131.100 - 254 | DHCP client addresses |
+| Broadcast | | 192.168.131.255 | |
diff --git a/docs/ros/networking/network_troubleshooting.mdx b/docs/ros/networking/network_troubleshooting.mdx
new file mode 100644
index 000000000..e339f4a3d
--- /dev/null
+++ b/docs/ros/networking/network_troubleshooting.mdx
@@ -0,0 +1,36 @@
+---
+title: Network Troubleshooting
+sidebar_position: 6
+---
+
+The following troubleshooting flowcharts cover many of the most common troubleshooting issues with network integrity and ROS 2 communication using FastDDS.
+
+### Network Integrity
+
+The first step to troubleshooting your system networking is to verify the network integrity. Click on the image below to open in a new tab and explore the troubleshooting steps.
+
+
+
+### ROS 2 Communication
+
+Once network integrity is confirmed, the next step is to troubleshoot being able to publish and subscribe to ROS topics. The following flowchart covers the most common networking errors in Fast DDS. Many of these concepts are transferrable to other DDS implementations. Click on the image below to open in a new tab and explore the troubleshooting steps.
+
+
diff --git a/docs/ros/networking/ntp.mdx b/docs/ros/networking/ntp.mdx
new file mode 100644
index 000000000..156a6eec5
--- /dev/null
+++ b/docs/ros/networking/ntp.mdx
@@ -0,0 +1,121 @@
+---
+title: Configuring NTP
+sidebar_position: 5
+---
+
+Network Time Protocol, or NTP, is a network protocol that allows computers on a network to synchronize their clocks
+with each other. This is essential for ROS, as many types of data are time-sensitive.
+
+### Chrony
+
+Clearpath uses a Linux package called `chrony` to provide clock synchronization across multiple devices inside a robot.
+The robot's primary computer acts as the main NTP source for other computers inside the robot.
+
+To (re-)configure `chrony`, edit the file `/etc/chrony/chrony.conf`. The following shows the default configuration
+for the primary computer:
+
+```
+# Welcome to the chrony configuration file. See chrony.conf(5) for more
+# information about usuable directives.
+
+# This will use (up to):
+# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
+# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
+# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
+# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
+# sources will be used.
+# At the same time it retains some protection against one of the entries being
+# down (compare to just using one of the lines). See (LP: #1754358) for the
+# discussion.
+#
+# About using servers from the NTP Pool Project in general see (LP: #104525).
+# Approved by Ubuntu Technical Board on 2011-02-08.
+# See http://www.pool.ntp.org/join.html for more information.
+pool ntp.ubuntu.com iburst maxsources 4
+pool 0.ubuntu.pool.ntp.org iburst maxsources 1
+pool 1.ubuntu.pool.ntp.org iburst maxsources 1
+pool 2.ubuntu.pool.ntp.org iburst maxsources 2
+
+# This directive specify the location of the file containing ID/key pairs for
+# NTP authentication.
+keyfile /etc/chrony/chrony.keys
+
+# This directive specify the file into which chronyd will store the rate
+# information.
+driftfile /var/lib/chrony/chrony.drift
+
+# Uncomment the following line to turn logging on.
+#log tracking measurements statistics
+
+# Log files location.
+logdir /var/log/chrony
+
+# Stop bad estimates upsetting machine clock.
+maxupdateskew 100.0
+
+# This directive enables kernel synchronisation (every 11 minutes) of the
+# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
+rtcsync
+
+# Step the system clock instead of slewing it if the adjustment is larger than
+# one second, but only in the first three clock updates.
+makestep 1 3
+
+# Configure this host to act as the NTP source for the rest of the devices in this robot
+local stratum 10
+allow 192.168.131/24
+```
+
+For secondary computers inside the robot, the `chrony` configuration file is very similar, but adds a new `server` directive
+after the `pool`, and omits the final `local` and `allow` sections:
+
+```
+# Welcome to the chrony configuration file. See chrony.conf(5) for more
+# information about usuable directives.
+
+# This will use (up to):
+# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
+# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
+# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
+# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
+# sources will be used.
+# At the same time it retains some protection against one of the entries being
+# down (compare to just using one of the lines). See (LP: #1754358) for the
+# discussion.
+#
+# About using servers from the NTP Pool Project in general see (LP: #104525).
+# Approved by Ubuntu Technical Board on 2011-02-08.
+# See http://www.pool.ntp.org/join.html for more information.
+pool ntp.ubuntu.com iburst maxsources 4
+pool 0.ubuntu.pool.ntp.org iburst maxsources 1
+pool 1.ubuntu.pool.ntp.org iburst maxsources 1
+pool 2.ubuntu.pool.ntp.org iburst maxsources 2
+
+# Add the robot's primary computer as an NTP source
+server 192.168.131.1 offline minpoll 8
+
+# This directive specify the location of the file containing ID/key pairs for
+# NTP authentication.
+keyfile /etc/chrony/chrony.keys
+
+# This directive specify the file into which chronyd will store the rate
+# information.
+driftfile /var/lib/chrony/chrony.drift
+
+# Uncomment the following line to turn logging on.
+#log tracking measurements statistics
+
+# Log files location.
+logdir /var/log/chrony
+
+# Stop bad estimates upsetting machine clock.
+maxupdateskew 100.0
+
+# This directive enables kernel synchronisation (every 11 minutes) of the
+# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
+rtcsync
+
+# Step the system clock instead of slewing it if the adjustment is larger than
+# one second, but only in the first three clock updates.
+makestep 1 3
+```
diff --git a/docs/ros/networking/overview.mdx b/docs/ros/networking/overview.mdx
new file mode 100644
index 000000000..ac88f9c64
--- /dev/null
+++ b/docs/ros/networking/overview.mdx
@@ -0,0 +1,54 @@
+---
+title: Overview
+sidebar_position: 1
+---
+
+import Ros2NetworkingOverview from "/docs_versioned_docs/version-ros2humble/components/networking/_ros2_networking_overview.mdx";
+
+### SSH and SFTP
+
+Clearpath robots ship with an SSH server operating on port 22 for remote login. This server also supports sftp for
+file-transfer to/from the robot if needed. By default you can log in using the default username and password for the
+robot.
+
+### Wired LAN IP Addresses {#ip-addresses}
+
+All Clearpath robots use the `192.168.131.0/24` subnet for any permanently-installed network hardware. This includes,
+but may not be limited to
+
+- the robot's primary computer,
+- the robot's MCU,
+- a secondary computer (if present),
+- any cameras, lidar, or other sensors that communicate over Ethernet, and
+- any long-range wireless radios.
+
+The `192.168.131.0/24` subnet is statically configured; all devices are configured to use a static IP address, and
+there is normally not a DHCP server operating on this subnet.
+
+For a list of standard payload IP addresses, please see [network IP addresses](network_ip_addresses.mdx).
+
+### ROS 2 Networking {#ros2-networking}
+
+
+
+Further information on [ROS 2 Networking](ros2-networking.mdx).
+
+:::tip
+
+For the best chance of success, use a high speed, high bandwidth network and monitor the network usage.
+
+:::
+
+### Clock Synchronization
+
+If your robot contains multiple computers, their clocks must remain synchronized to allow proper communication between
+ROS nodes running on each one. Clearpath configures the computers to use `chrony` to synchronize the clocks, with the
+primary computer being the authoritative source for the others.
+
+For details on configuring `chrony`, please see [configuring NTP](ntp.mdx).
+
+:::note
+
+Contact our Support team at \ if you have any questions.
+
+:::
\ No newline at end of file
diff --git a/docs/ros/networking/ros2-networking.mdx b/docs/ros/networking/ros2-networking.mdx
new file mode 100644
index 000000000..1ad3286f6
--- /dev/null
+++ b/docs/ros/networking/ros2-networking.mdx
@@ -0,0 +1,242 @@
+---
+title: ROS 2 Networking
+sidebar_position: 3
+---
+
+## Overview
+
+import Ros2NetworkingOverview from "/docs_versioned_docs/version-ros2humble/components/networking/_ros2_networking_overview.mdx";
+
+
+
+## How Discovery Works
+
+### Simple Discovery
+
+Participants (nodes) send periodic multicast announcement messages over the network with their unicast addresses, and
+then all participants share discovery information (such as topics, and action servers.) with all other participants.
+This means that all participants get information about all other participants irrelevant of whether or not they need
+that information.
+
+The following diagram depicts three Husky A200's set up with simple discovery and illustrates how different
+combinations of settings work. The robot type is not important, and the same diagram can be made for any
+combination of Clearpath robots.
+
+
+
+
+
+
+
+For more detailed information regarding Fast DDS or simple discovery, visit the
+[eProsima Fast DDS documentation](https://fast-dds.docs.eprosima.com/en/latest/fastdds/ros2/ros2.html).
+
+Additional details on how to select simple disocvery in the `robot.yaml` config file are available in the
+[Middleware section of Robot Configuration](../config/yaml/system.mdx#middleware).
+
+### Discovery Server
+
+A discovery server is a process running on a computer that serves to record and report ROS discovery information.
+A server can be thought of as a look up table for ROS discovery information. When a participant (node) starts, it
+checks in with the servers to share its discovery information and request what information it is looking for.
+In this way, particpants only get discovery information and establish communication as necessary. A participant
+does not know all of the information that is available, only where to find the fellow participants that it needs.
+
+There can be multiple servers in a given system. These can be used for redundancy or to segregate information.
+
+The following diagram depicts three Husky A200's set up with discovery server and illustrates how different
+combinations of settings work. The `ROS_DISCOVERY_SERVER` environment variable indicates which discovery servers
+a given robot should communicate with. The robot type is not important and the same diagram can be made for any
+combination of Clearpath robots.
+
+
+
+
+
+
+
+For more detailed information regarding Fast DDS or discovery server, visit the
+[eProsima Fast DDS documentation](https://fast-dds.docs.eprosima.com/en/latest/fastdds/ros2/ros2.html).
+
+## Choosing a Configuration
+
+The first decision is choosing between simple discovery and discovery server. If simple discovery works for you then
+there is no need to change from the default operation. Simple discovery generally allows for any ROS 2 and Fast DDS
+enabled device running the default settings to connect to the system with no additional configuration.
+
+:::tip
+
+If you want to run multiple independent simple discovery systems on the same network, you can segregate them by
+using different ROS Domain IDs.
+
+:::
+
+You may want or need to switch to discovery server for any of the following reasons:
+- If your network does not support multicasting (often true on school or corporate networks)
+- If you have a large system (several robots or an excess number of nodes/topics)
+- If you want to control which devices have access to which information
+- If you have a weak network (for example in cases of long range wireless connection)
+
+:::note
+
+Certain networks (such as school or corporate networks) may have additional restrictions that prevent even
+ROS 2 with discovery server from operating. In these situations consider meeting with the IT group or the network
+administrator to determine if ROS 2 is allowed to run on that network or if you can run the system on a separate
+dedicated network.
+
+:::
+
+## Discovery Server Configurations
+
+There are multiple different ways to configure discovery server depending on which ROS 2 devices need to connect.
+This section will go over some basic configurations and is generalized for use as an introduction. It does not
+describe all possible configurations. The `ROS_DISCOVERY_SERVER` environment variable, shown in the various diagrams,
+indicates which discovery servers a given robot is connected to. Additionally, communication will be referred to
+in terms of seeing ROS 2 topics although this is representative of all nodes, topics, action servers, and so on.
+
+:::note
+
+For all configurations, it is very important for all discovery servers in the system to be included in the `servers`
+list in the `robot.yaml` config. This is because each discovery server must have a unique ID number which
+is used both to launch the server and to connect to the server. This ID is automatically assigned by the Clearpath
+packages.
+
+:::
+
+### 1. Fully Connected {#fully-connected}
+
+This configuration is the simplest to set up using the `robot.yaml` config. It allows all robots to operate
+independently but also allows any ROS 2 device in the system to see all of the topics from all of the
+ROS 2 devices. This is done by having a local discovery server on each robot and pointing each ROS 2 device
+in the system at all of the discovery servers in the system.
+
+
+
+
+
+
+
+This configuration is achieved by listing all of the computers' hostnames in the
+[`servers` section](../config/yaml/system.mdx#servers) on all of the robots. Including the offboard computer allows
+the offboard computer to also have a discovery server running and thus operate independently from the robots as
+well as communicating with all of the robots. However, the discovery server must also be set up separately on the
+offboard computer (only required to allow the offboard computer to run ROS 2 nodes independently from the robots).
+
+The middleware section for the system in the diagram would look like the following on all devices:
+
+```yaml
+middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: server
+ servers:
+ - hostname: cpr-a200-0000
+ - hostname: cpr-a200-0001
+ - hostname: offboard-computer
+```
+
+Additional details on the available fields for the `robot.yaml` config file are available in the
+[Middleware section of Robot Configuration](../config/yaml/system.mdx#middleware).
+
+### 2. Command Center {#command-center}
+
+In this configuration you have many robots that each operate independently and an offboard computer that
+checks in and communicates with each of the robots. Each of the robots will have and refer to their own local
+discovery server. This allows the onboard ROS 2 nodes to communicate without any external network connection.
+The offboard computer will be pointed at the discovery servers on each and every robot. This will allow the
+offboard computer to see all of the topics on all of the robots at the same time. In turn, each of the robots will be
+able to see all of the topics launched on the offboard computer. Including a discovery server on the offboard computer as well
+allows it to run ROS 2 nodes independently from the robots.
+
+The key difference between this configuration and the fully connected configuration is that the robots cannot
+communicate with each other. This may be beneficial if the network is weak, or if there is an excess number of
+robots.
+
+
+
+
+
+
+
+This configuration is achieved by listing all of the computers' hostnames in the
+[`servers` section](../config/yaml/system.mdx#servers) on all of the robots but setting `enabled` to `False` for
+every server entry except for that specific robot. This tells the robot to only use its own discovery server.
+The offboard computer should have all of the servers enabled, telling it to connect to all discovery servers in the system.
+This servers list must include the offboard computer if a discovery server is being run on the offboard computer. However, the discovery
+server must also be set up separately on the offboard computer.
+
+The middleware section of the config for the system in the diagram would look like the following for `cpr-a200-0000`:
+
+```yaml
+middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: server
+ servers:
+ - hostname: cpr-a200-0000
+ - hostname: cpr-a200-0001
+ enabled: False
+ - hostname: offboard-computer
+ enabled: False
+```
+
+It would look like the following for `cpr-a200-0001`:
+
+```yaml
+middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: server
+ servers:
+ - hostname: cpr-a200-0000
+ enabled: False
+ - hostname: cpr-a200-0001
+ - hostname: offboard-computer
+ enabled: False
+```
+
+And the following for the offboard computer:
+
+```yaml
+middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: server
+ servers:
+ - hostname: cpr-a200-0000
+ - hostname: cpr-a200-0001
+ - hostname: offboard-computer
+```
+
+Additional details on the available fields for the `robot.yaml` config file are available in the
+[Middleware section of Robot Configuration](../config/yaml/system.mdx#middleware).
+
+## Offboard Computer Setup {#offboard-pc}
+
+Use the `robot.yaml` from one of the robots in order to set up the offboard computer. The `servers` list must include all of
+the discovery servers and all of the ones that the offboard computer should be connecting with must not be disabled.
+
+1. Regenerate the `setup.bash` every time the `servers` list changes in any way (as per [offboard computer install instructions](../installation/offboard_pc.mdx#setup-folder))
+
+2. If a discovery server is intended to be run on the offboard computer then generate and run the discovery-server-start launch file.
+
+To generate the launch script:
+
+```
+source /opt/ros/humble/setup.bash
+ros2 run clearpath_generator_common generate_discovery_server -s ~/clearpath
+```
+
+To launch the server
+
+```
+bash -e ~/clearpath/discovery-server-start
+```
diff --git a/docs/ros/ros.mdx b/docs/ros/ros.mdx
new file mode 100644
index 000000000..1c3fe7e47
--- /dev/null
+++ b/docs/ros/ros.mdx
@@ -0,0 +1,93 @@
+---
+title: Robot Operating System 2 (ROS 2) Overview
+sidebar_label: ROS 2 Overview
+sidebar_position: 1
+---
+
+For [ROS 2 Humble](https://docs.ros.org/en/humble/index.html) and beyond, the software structure of Clearpath
+robots has changed significantly. Rather than having individual sets of packages for each robot, we have opted to
+create common `clearpath` packages which are used by all supported platforms. Additionally, we are moving away from
+using environment variables to customize the robot, and instead using a YAML configuration file to describe the
+robot. We have also defined a [ROS 2 API](api/overview.mdx) common to all of our supported platforms. As a result,
+our platforms are now more customizable, more modular, and more unified.
+
+## Terminology {#terminology}
+
+**_Clearpath Platform_**: The _platform_ refers to the vehicle that makes up the base of the robot. The platform
+may be referred to by the platform code to indicate the revision.
+
+**_Clearpath Robot_**: The _robot_ refers to the entire robotic system, including the platform, sensors, and additional accessories.
+
+**_Clearpath Config_**: The _config_ refers to the `robot.yaml` configuration file that defines the Clearpath robot.
+
+**_Clearpath API_**: The _API_ refers to the [ROS 2 application programming interface](api/overview.mdx). This is a set
+of ROS 2 topics and services defined by Clearpath which are used by all supported Clearpath platforms.
+
+## Supported Platforms {#supported-platforms}
+
+| Platform | Platform code | Supports ROS 2 Humble (amd64) | (arm64) |
+| :-------- | :------------ | :---------------------------- | :------ |
+| Husky | A200 | Yes (As of 0.1) | Coming |
+| Jackal | J100 | Yes (As of 0.1) | Coming |
+| Warthog | W200 | Yes (As of 0.2) | Coming |
+| Dingo | DD100 | Yes (As of 0.3) | Coming |
+| | DO100 | Coming | Coming |
+| | DD150 | Yes (As of 0.3) | Coming |
+| | DO150 | Coming | Coming |
+| Ridgeback | R100 | Yes (As of 0.3) | Coming |
+| Boxer | B250 | No | No |
+
+
+## Supported Sensors {#supported-sensors}
+
+:::note
+
+While some sensor drivers may support other sensor models, the table below represents the
+sensors that have been validated by Clearpath.
+
+:::
+
+| Sensor | Type | Installation | Driver |
+| :----------------------------------------------------------------------------------- | :----------- | :----------- | :------------------------------------------------------------------------------------------ |
+| [SICK LMS-111/LMS-151](../robots/accessories/sensors/lidar_2d/sick_lms111.mdx) | 2D Lidar | Debian | [LMS1xx](https://github.com/clearpathrobotics/LMS1xx) |
+| [Hokuyo UST10-LX](../robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx) | 2D Lidar | Debian | [urg_node](https://github.com/ros-drivers/urg_node) |
+| [Hokuyo UST20-LX](../robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx) | 2D Lidar | Debian | [urg_node](https://github.com/ros-drivers/urg_node) |
+| [Hokuyo UST30-LX](../robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx) | 2D Lidar | Debian | [urg_node](https://github.com/ros-drivers/urg_node) |
+| [MicroStrain 3DM-GX5](../robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx) | IMU | Debian | [microstrain_intertial](https://github.com/LORD-MicroStrain/microstrain_inertial/tree/ros2) |
+| [MicroStrain 3DM-GQ7](../robots/accessories/sensors/gps/microstrain_gq7.mdx) | GPS/IMU | Debian | [microstrain_intertial](https://github.com/LORD-MicroStrain/microstrain_inertial/tree/ros2) |
+| [Redshift Labs UM7](../robots/accessories/sensors/imu/redshift_labs_um7.mdx) | IMU | Debian | [um7](https://github.com/ros-drivers/um7/tree/ros2) |
+| CH Robotics UM6 | IMU | Debian | [um7](https://github.com/ros-drivers/um7/tree/ros2) |
+| [Velodyne Puck](../robots/accessories/sensors/lidar_3d/velodyne_puck.mdx) | 3D Lidar | Debian | [velodyne](https://github.com/ros-drivers/velodyne/tree/ros2) |
+| [Garmin GPS 18x](../robots/accessories/sensors/gps/garmin_gps_18x.mdx) | GPS | Debian | [nmea_navsat_driver](https://github.com/ros-drivers/nmea_navsat_driver/tree/ros2) |
+| NovAtel SMART6 and SMART7 | GPS | Debian | [nmea_navsat_driver](https://github.com/ros-drivers/nmea_navsat_driver/tree/ros2) |
+| [Swift Navigation Duro](../robots/accessories/sensors/gps/swift_navigation_duro.mdx) | GPS | Source | [duro_gps_driver](https://github.com/szenergy/duro_gps_driver/tree/ros2-humble) |
+| [Flir Blackfly S](../robots/accessories/sensors/cameras/flir_blackfly_s.mdx) | Camera | Debian | [flir_camera_driver](https://github.com/ros-drivers/flir_camera_driver/tree/humble-devel) |
+| [Intel Realsense D435](../robots/accessories/sensors/cameras/realsense_d435.mdx) | Depth Camera | Debian | [realsense-ros](https://github.com/IntelRealSense/realsense-ros/tree/ros2-development) |
+| [Stereolabs Zed 2](../robots/accessories/sensors/cameras/stereolabs_zed_2.mdx) | Depth Camera | Source | [zed-ros2-wrapper](https://github.com/stereolabs/zed-ros2-wrapper.git) |
+
+:::note
+
+Debian drivers are automatically installed on robots as part of the
+[Clearpath Robot Metapackage](../ros/installation/robot.mdx#clearpath-robot-metapackage).
+
+:::
+
+## Changelog
+
+### [0.3.0] 2024-09-10
+:::warning
+The `StopStatus` message in `clearpath_msgs` has an additional field in the `0.3.0` release. This message type is used by the MicroROS enabled, robot MCU; therefore, the firmware must be updated on all robot platforms, except the A200. See, the [robot installation section](./installation/robot.mdx#firmware-update) for information on updating the firmware.
+:::
+#### New Features
+ - DD100 and DD150 Platform and [Attachments](./config/yaml/platform/attachments/dx1X0.mdx)
+ - R100 Platform and [Attachments](./config/yaml/platform/attachments/r100.mdx)
+ - [Manipulator Generators](./config/generators.mdx#manipulation-generation)
+ - MoveIt! Configuration Generation
+ - [Kinova Gen3 Lite, 6Dof, and 7Dof Arms](./config/yaml/manipulators.mdx#kinova-arms)
+ - [Robotiq 2F 85 and 140 Grippers](./config/yaml/manipulators.mdx#robotiq-grippers)
+
+#### Changed
+ - `StopStatus` message added `needs_reset` parameter for R100 platform.
+
+#### Fixed
+ - Use `StopStatus` message to set lighting state
diff --git a/docs/ros/tutorials/_category_.json b/docs/ros/tutorials/_category_.json
new file mode 100644
index 000000000..38acf2559
--- /dev/null
+++ b/docs/ros/tutorials/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Tutorials",
+ "position": 6
+}
diff --git a/docs/ros/tutorials/driving.mdx b/docs/ros/tutorials/driving.mdx
new file mode 100644
index 000000000..b12fb4fd8
--- /dev/null
+++ b/docs/ros/tutorials/driving.mdx
@@ -0,0 +1,72 @@
+---
+title: Driving a Robot
+sidebar_label: Driving a Robot
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+:::caution
+
+Make sure you have successfully [set up](../installation/robot.mdx) the robot before attempting to drive it.
+
+:::
+
+There are several ways to drive a Clearpath robot using ROS 2.
+
+### Joystick Teleoperation
+
+Make sure your controller is paired to the robot computer. Visit the [controller pairing](../installation/controller.mdx) guide for details.
+
+With the [robot services](../installation/robot.mdx#robot-services) running, turn on your controller. Press and hold
+either **L1** or **R1**, and use the left joystick to publish a linear velocity and yaw command. The **L1** button
+will drive the robot at slow speeds, while **R1** will drive the robot at fast speeds (only supported on some robots).
+
+
+
+
+ PS4 Contoller
+
+
+
+### Keyboard Teleoperation
+
+Install the `teleop_twist_keyboard` ROS 2 package on the robot computer or on an offboard computer:
+
+```
+sudo apt-get update
+sudo apt-get install ros-humble-teleop-twist-keyboard
+```
+
+Once installed, run the node:
+
+```
+ros2 run teleop_twist_keyboard teleop_twist_keyboard
+```
+
+If your robot uses a namespace, the namespace should be applied to `teleop_twist_keyboard`:
+
+```
+ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -r __ns:=/j100_0001
+```
+
+### Command Velocity
+
+You can manually publish to the `cmd_vel` topic through the command line by calling:
+
+```
+ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \
+"linear:
+ x: 0.0
+ y: 0.0
+ z: 0.0
+angular:
+ x: 0.0
+ y: 0.0
+ z: 0.0"
+```
+
+Set the `linear.x` value to drive the robot forwards or backwards, and the `angular.z` value to rotate left or right.
diff --git a/docs/ros/tutorials/manipulation/_category_.json b/docs/ros/tutorials/manipulation/_category_.json
new file mode 100644
index 000000000..f5b719856
--- /dev/null
+++ b/docs/ros/tutorials/manipulation/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Manipulation Demos",
+ "position": 4
+}
diff --git a/docs/ros/tutorials/manipulation/gazebo.mdx b/docs/ros/tutorials/manipulation/gazebo.mdx
new file mode 100644
index 000000000..52b564f4c
--- /dev/null
+++ b/docs/ros/tutorials/manipulation/gazebo.mdx
@@ -0,0 +1,90 @@
+---
+title: Manipulation in Gazebo Ignition
+sidebar_label: Manipulation in Simulation
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Simulating an arm in Gazebo Ignition is a safe alternative to test path planning and execution MoveIt! plugins, MoveIt! commander scripts, or simple commands completely independent of the MoveIt! libraries. We facilitate the process of setting up simulations, by providing a customizable, simulated mobile robot platform with sensors and manipulators utilizing the Clearpath Configuration System.
+
+In this tutorial, we will cover using the MoveIt! Planning and Execution RViz plug-in to move arms to a predefined pose. We will use the A200 platform with a Kinova Gen3 Lite in the [Clearpath simulator](../simulator/overview.mdx).
+
+The `robot.yaml` configuration we will use is included below.
+
+
+A200 YAML
+
+
+
+## Launching the Simulation
+Move the `robot.yaml` file to your setup directory (`$HOME/clearpath` by default).
+
+Launch the simulation
+```
+ros2 launch clearpath_gz simulation.launch.py setup_path:=$HOME/clearpath
+```
+
+Click on the orange play button in the bottom left corner to start the simulation.
+
+At this point, you will have the platform and manipulator controllers loaded and activated; you can send joint commands to the manipulators and velocity commands to the platform. However, depending on the joint states sent, the manipulators may collide with itself or the platform. Therefore, it is recommended to use MoveIt! to plan and execute collision free paths.
+
+## Launching MoveIt!
+Launch MoveIt! by passing the same robot setup directory and setting the simulation flag.
+```
+ros2 launch clearpath_manipulators moveit.launch.py setup_path:=$HOME/clearpath use_sim_time:=true
+```
+
+Now, you have the `move_group` node that can be utilized to send a joint or pose goal to a specific manipulation group. However, for this tutorial, we will cover how to visualize the arm in RViz and send goals through the plug-in.
+
+## Launching RViz
+Launch RViz by passing the robot's namespace and enabling the simulation flag.
+```
+ros2 launch clearpath_viz view_moveit.launch.py namespace:=a200_0000 use_sim_time:=True
+```
+:::note
+The namespace is defined in the `robot.yaml` using the `system.ros2.namespace` parameter.
+:::
+
+
+
+
+
+ MoveIt! planning and execution in simulation
+
+
diff --git a/docs/ros/tutorials/manipulation/img/moveit_gazebo.gif b/docs/ros/tutorials/manipulation/img/moveit_gazebo.gif
new file mode 100644
index 000000000..3ee800c88
Binary files /dev/null and b/docs/ros/tutorials/manipulation/img/moveit_gazebo.gif differ
diff --git a/docs/ros/tutorials/navigation_demos/_category_.json b/docs/ros/tutorials/navigation_demos/_category_.json
new file mode 100644
index 000000000..1f9c6a20f
--- /dev/null
+++ b/docs/ros/tutorials/navigation_demos/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Navigation Demos",
+ "position": 3
+}
diff --git a/docs/ros/tutorials/navigation_demos/img/localization.gif b/docs/ros/tutorials/navigation_demos/img/localization.gif
new file mode 100644
index 000000000..a0e1b334f
Binary files /dev/null and b/docs/ros/tutorials/navigation_demos/img/localization.gif differ
diff --git a/docs/ros/tutorials/navigation_demos/img/nav2.gif b/docs/ros/tutorials/navigation_demos/img/nav2.gif
new file mode 100644
index 000000000..74f78fb81
Binary files /dev/null and b/docs/ros/tutorials/navigation_demos/img/nav2.gif differ
diff --git a/docs/ros/tutorials/navigation_demos/img/slam.gif b/docs/ros/tutorials/navigation_demos/img/slam.gif
new file mode 100644
index 000000000..db138bfc4
Binary files /dev/null and b/docs/ros/tutorials/navigation_demos/img/slam.gif differ
diff --git a/docs/ros/tutorials/navigation_demos/localization.mdx b/docs/ros/tutorials/navigation_demos/localization.mdx
new file mode 100644
index 000000000..92153cbdf
--- /dev/null
+++ b/docs/ros/tutorials/navigation_demos/localization.mdx
@@ -0,0 +1,132 @@
+---
+title: Localization
+sidebar_label: Localization
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Localization is a method of tracking the robot's location within an existing map. It is generally done using
+laser scan data from a 2D LIDAR, and the robot's odometry. For this demo we are using the
+[Nav2](https://github.com/ros-planning/navigation2) package launch localization.
+
+This tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical
+robot too. We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
+
+
+ J100 YAML
+
+
+
+:::tip
+
+Make sure you have installed the simulator before starting this tutorial. Take a look at the
+[installation](../simulator/install.mdx) guide for details.
+
+:::
+
+## Launching the simulation and localization
+
+**1. Move the `robot.yaml` file to your setup folder (`$HOME/clearpath` by default).**
+
+**2. Launch the simulation**
+
+```
+ros2 launch clearpath_gz simulation.launch.py
+```
+
+Click on the orange play button in the bottom left corner to start the simulation.
+
+**3. In another terminal, launch RViz**
+
+```
+ros2 launch clearpath_viz view_navigation.launch.py namespace:=j100_0001
+```
+
+**4. In another terminal, launch localization**
+
+```
+ros2 launch clearpath_nav2_demos localization.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true
+```
+
+The default map used by `localization.launch.py` is a
+[map](https://github.com/clearpathrobotics/clearpath_nav2_demos/blob/main/maps/warehouse.yaml) of the simulated warehouse world.
+If you are using a custom map, pass it in with the `map` launch argument:
+
+```
+ros2 launch clearpath_nav2_demos localization.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true map:=/path/to/my/map.yaml
+```
+
+**5. Set the initial pose of the robot**
+
+Use the **2D Pose Estimate** tool in RViz to set the initial pose of the robot. You can now drive the robot
+and it will calculate its position on the map.
+
+
+
+
+ Localization in simulation
+
+
diff --git a/docs/ros/tutorials/navigation_demos/nav2.mdx b/docs/ros/tutorials/navigation_demos/nav2.mdx
new file mode 100644
index 000000000..e56c916c0
--- /dev/null
+++ b/docs/ros/tutorials/navigation_demos/nav2.mdx
@@ -0,0 +1,140 @@
+---
+title: Nav2
+sidebar_label: Nav2
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+The [Nav2](https://github.com/ros-planning/navigation2) package provides open source navigation controllers,
+planners, and utilities. The [clearpath_nav2_demos](https://github.com/clearpathrobotics/clearpath_nav2_demos/tree/main) package
+provides default configurations for supported robots, but these can be customized for your use case. This
+tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical robot too.
+We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
+
+
+ J100 YAML
+
+
+
+:::tip
+
+Make sure you have installed the simulator before starting this tutorial. Take a look at the
+[installation](../simulator/install.mdx) guide for details.
+
+:::
+
+## Launching the simulation and Nav2
+
+**1. Move the `robot.yaml` file to your setup folder (`$HOME/clearpath` by default).**
+
+**2. Launch the simulation**
+
+```
+ros2 launch clearpath_gz simulation.launch.py
+```
+
+Click on the orange play button in the bottom left corner to start the simulation.
+
+**3. In another terminal, launch RViz**
+
+```
+ros2 launch clearpath_viz view_navigation.launch.py namespace:=j100_0001
+```
+
+**4. In another terminal, launch localization**
+
+```
+ros2 launch clearpath_nav2_demos localization.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true
+```
+
+The default map used by `localization.launch.py` is a
+[map](https://github.com/clearpathrobotics/clearpath_nav2_demos/blob/main/maps/warehouse.yaml) of the simulated warehouse world.
+If you are using a custom map, pass it in with the `map` launch argument:
+
+```
+ros2 launch clearpath_nav2_demos localization.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true map:=/path/to/my/map.yaml
+```
+
+**5. In another terminal, launch Nav2**
+
+```
+ros2 launch clearpath_nav2_demos nav2.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true
+```
+
+**6. Set the initial pose of the robot**
+
+Use the **2D Pose Estimate** tool in RViz to set the initial pose of the robot.
+
+7. Give the robot a navigation goal
+
+Use the **Nav2 Goal** tool in RViz to set a navigation goal pose.
+
+
+
+
+ Navigation in simulation
+
+
diff --git a/docs/ros/tutorials/navigation_demos/overview.mdx b/docs/ros/tutorials/navigation_demos/overview.mdx
new file mode 100644
index 000000000..1d4106567
--- /dev/null
+++ b/docs/ros/tutorials/navigation_demos/overview.mdx
@@ -0,0 +1,25 @@
+---
+title: Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+The [clearpath_nav2_demos](https://github.com/clearpathrobotics/clearpath_nav2_demos) package contains
+launch files and configurations for [Nav2](https://github.com/ros-planning/navigation2) and
+[slam_toolbox](https://github.com/SteveMacenski/slam_toolbox) demos. These are open source
+navigation packages that allow Clearpath robots to create maps and autonomously navigate.
+
+To install the package, run:
+
+```
+sudo apt-get update
+sudo apt-get install ros-humble-clearpath-nav2-demos
+```
+
+:::tip
+
+The navigation demos can be run on either the robot computer, or an offboard computer.
+
+:::
diff --git a/docs/ros/tutorials/navigation_demos/slam.mdx b/docs/ros/tutorials/navigation_demos/slam.mdx
new file mode 100644
index 000000000..3b5456a0b
--- /dev/null
+++ b/docs/ros/tutorials/navigation_demos/slam.mdx
@@ -0,0 +1,126 @@
+---
+title: SLAM
+sidebar_label: SLAM
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 5
+---
+
+Simultaneous localization and mapping (SLAM) is a method of generating a map and tracking the robot's
+location within the map. It is generally done using
+laser scan data from a 2D LIDAR, and the robot's odometry. For this demo we are using the
+[slam_toolbox](https://github.com/SteveMacenski/slam_toolbox) package to map our environment.
+This tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical
+robot too. We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
+
+
+ J100 YAML
+
+
+
+:::tip
+
+Make sure you have installed the simulator before starting this tutorial. Take a look at the
+[installation](../simulator/install.mdx) guide for details.
+
+:::
+
+## Launching the simulation and SLAM
+
+**1. Move the `robot.yaml` file to your setup folder (`$HOME/clearpath` by default).**
+
+**2. Launch the simulation**
+
+```
+ros2 launch clearpath_gz simulation.launch.py
+```
+
+Click on the orange play button in the bottom left corner to start the simulation.
+
+**3. In another terminal, launch RViz**
+
+```
+ros2 launch clearpath_viz view_navigation.launch.py namespace:=j100_0001
+```
+
+**4. In another terminal, launch SLAM**
+
+```
+ros2 launch clearpath_nav2_demos slam.launch.py setup_path:=$HOME/clearpath/ use_sim_time:=true
+```
+
+**5. Drive the robot around the world until the entire map has been generated**
+
+
+
+
+ SLAM in simulation
+
+
+
+**6. Save the map**
+
+```
+ros2 run nav2_map_server map_saver_cli -f "map_name" \
+--ros-args -p map_subscribe_transient_local:=true -r __ns:=/j100_0001
+```
diff --git a/docs/ros/tutorials/simulator/_category_.json b/docs/ros/tutorials/simulator/_category_.json
new file mode 100644
index 000000000..a52456b92
--- /dev/null
+++ b/docs/ros/tutorials/simulator/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Simulator",
+ "position": 2
+}
diff --git a/docs/ros/tutorials/simulator/img/driving.gif b/docs/ros/tutorials/simulator/img/driving.gif
new file mode 100644
index 000000000..7a59aff30
Binary files /dev/null and b/docs/ros/tutorials/simulator/img/driving.gif differ
diff --git a/docs/ros/tutorials/simulator/img/simulation.png b/docs/ros/tutorials/simulator/img/simulation.png
new file mode 100644
index 000000000..37ce60bfc
Binary files /dev/null and b/docs/ros/tutorials/simulator/img/simulation.png differ
diff --git a/docs/ros/tutorials/simulator/install.mdx b/docs/ros/tutorials/simulator/install.mdx
new file mode 100644
index 000000000..177f1231b
--- /dev/null
+++ b/docs/ros/tutorials/simulator/install.mdx
@@ -0,0 +1,68 @@
+---
+title: Installing Clearpath Simulator
+sidebar_label: Installation
+sidebar_position: 2
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+:::tip
+
+It is highly recommended to install the simulator on a computer with a dedicated GPU for optimal performance.
+
+:::
+
+### Computer Setup
+
+Follow the [Offboard Computer](../../installation/offboard_pc.mdx) setup guide.
+
+### Installing Gazebo Fortress
+
+Run the following commands in your terminal:
+
+```
+sudo apt-get update && sudo apt-get install wget
+sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-stable `lsb_release -cs` main" > /etc/apt/sources.list.d/gazebo-stable.list'
+wget http://packages.osrfoundation.org/gazebo.key -O - | sudo apt-key add -
+sudo apt-get update && sudo apt-get install ignition-fortress
+```
+
+### Installing Clearpath Simulator
+
+Run the following commands in your terminal:
+
+```
+sudo apt-get update
+sudo apt-get install ros-humble-clearpath-simulator
+```
+
+#### Source install
+
+**1. Create a workspace on the robot's computer**
+
+```
+mkdir ~/clearpath_ws/src -p
+```
+
+**2. Import dependencies**
+
+```
+source /opt/ros/humble/setup.bash
+sudo apt install python3-vcstool
+cd ~/clearpath_ws
+wget https://raw.githubusercontent.com/clearpathrobotics/clearpath_simulator/main/dependencies.repos
+vcs import src < dependencies.repos
+rosdep install -r --from-paths src -i -y
+```
+
+**3. Build packages**
+
+```
+colcon build --symlink-install
+```
+
+:::note
+
+Make sure to add the workspace to your [robot.yaml](../../config/yaml/system.mdx) file.
+
+:::
diff --git a/docs/ros/tutorials/simulator/overview.mdx b/docs/ros/tutorials/simulator/overview.mdx
new file mode 100644
index 000000000..4832a24a7
--- /dev/null
+++ b/docs/ros/tutorials/simulator/overview.mdx
@@ -0,0 +1,30 @@
+---
+title: Overview
+sidebar_label: Overview
+sidebar_position: 1
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+The Clearpath simulator uses [Gazebo Fortress](https://gazebosim.org/home) to simulate robots in a physics-based
+environment. The simulation supports the [Clearpath Config](../../../ros/ros.mdx#terminology), as well as simulating
+multiple robots simultaneously. Gazebo data is bridged to ROS 2, and follows the [Clearpath API](../../api/overview.mdx).
+The Clearpath simulator can be used to iterate on robot configurations, test controls, develop navigation software, and much more.
+
+
+
+
+ Clearpath Simulator
+
+
+
+### Bridging Gazebo to ROS 2
+
+Gazebo uses its own transport layer consisting of nodes and messages similar to ROS 2. A
+[ROS 2 bridge node](https://github.com/gazebosim/ros_gz/tree/humble/ros_gz_bridge) is required to bridge
+Gazebo data to ROS 2, and vice versa. By leveraging the [generators](../../config/generators.mdx), we can
+generate the required bridges when the simulator is launched. As a result, the simulator can support all
+of the same configurations that a physical robot supports.
diff --git a/docs/ros/tutorials/simulator/simulate.mdx b/docs/ros/tutorials/simulator/simulate.mdx
new file mode 100644
index 000000000..2ba5b5739
--- /dev/null
+++ b/docs/ros/tutorials/simulator/simulate.mdx
@@ -0,0 +1,75 @@
+---
+title: Simulate
+sidebar_label: Simulate
+sidebar_position: 3
+toc_min_heading_level: 2
+toc_max_heading_level: 4
+---
+
+Once the simulator has been [installed](install.mdx), you can launch the simulation.
+
+## Launching the simulator
+
+Launch files for the simulation can be found in the `clearpath_gz` package, which is installed as part of the `clearpath_simulator`
+metapackage. The default launch file for launching the simulation environment and spawning your robot is
+[simulation.launch.py](https://github.com/clearpathrobotics/clearpath_simulator/blob/main/clearpath_gz/launch/simulation.launch.py).
+
+It can be called like this:
+
+```
+ros2 launch clearpath_gz simulation.launch.py
+```
+
+The launch file will run all of the necessary [generators](../../config/generators.mdx) to generate launch and parameter
+files for the simulation before launching Gazebo and spawning the robot. These will be placed under the setup path
+(defaults to `$HOME/clearpath/`).
+
+### Launch arguments
+
+If you are using a different setup path, use the `setup_path` launch argument to change it:
+
+```
+ros2 launch clearpath_gz simulation.launch.py setup_path:=$HOME/setup/path/
+```
+
+The Gazebo world (defaults to `warehouse`) can be changed using the `world` launch argument:
+
+```
+ros2 launch clearpath_gz simulation.launch.py world:=my_world
+```
+
+:::note
+
+The launch file will look for the world `.sdf` file inside the
+[worlds](https://github.com/clearpathrobotics/clearpath_simulator/tree/main/clearpath_gz/worlds)folder of the `clearpath_gz` package.
+
+:::
+
+The position and orientation of where the robot is spawned can be changed:
+
+```
+ros2 launch clearpath_gz simulation.launch.py x:=1.5 y:=2.7 yaw:=1.5707
+```
+
+To launch Rviz along with the simulation, use the `rviz` launch argument:
+
+```
+ros2 launch clearpath_gz simulation.launch.py rviz:=true
+```
+
+## Driving the robot
+
+The simulated robot can be driven in the same ways as the physical robot. Take a look at the [Teleop](../driving.mdx)
+guide for details. In addition, the Gazebo Teleop GUI plugin can be used. The plugin will be visible by default when
+Gazebo is launched. If your robot has a namespace, change the topic to `/cmd_vel`. Set the maximum forward
+and yaw velocities, then select the method of driving.
+
+
+
+
+ Driving Jackal in simulation
+
+
diff --git a/docs_indoornav_user_manual/base_robot_config/config_apt_rosdep.mdx b/docs_indoornav_user_manual/base_robot_config/config_apt_rosdep.mdx
index bdb4bfe4c..ce76ca5b1 100644
--- a/docs_indoornav_user_manual/base_robot_config/config_apt_rosdep.mdx
+++ b/docs_indoornav_user_manual/base_robot_config/config_apt_rosdep.mdx
@@ -47,20 +47,20 @@ rosdep update
:::note
Complete ROS Noetic installation instructions can be found at
-
+http://wiki.ros.org/noetic/Installation/Ubuntu
:::
:::note
Complete ROS 2 Foxy installation instructions can be found at
-
+https://docs.ros.org/en/foxy/Installation/Ubuntu-Install-Debians.html
:::
:::note
Complete instructions for Clearpath APT sources can be found at
-
+http://packages.clearpathrobotics.com
:::
diff --git a/docs_indoornav_user_manual/base_robot_config/config_install_robot_os.mdx b/docs_indoornav_user_manual/base_robot_config/config_install_robot_os.mdx
index e4e1bc6fe..754689066 100644
--- a/docs_indoornav_user_manual/base_robot_config/config_install_robot_os.mdx
+++ b/docs_indoornav_user_manual/base_robot_config/config_install_robot_os.mdx
@@ -37,4 +37,4 @@ Ubuntu 20.04 and ROS Noetic on all robots that support IndoorNav:
You can download the latest version of Clearpath's ROS Noetic + Ubuntu
20.04 `Focal` installation media for 64-bit Intel or AMD CPUs here:
-.
+\.
diff --git a/docs_indoornav_user_manual/installing_backpack_software.mdx b/docs_indoornav_user_manual/installing_backpack_software.mdx
index 291adc1cc..e1c347981 100644
--- a/docs_indoornav_user_manual/installing_backpack_software.mdx
+++ b/docs_indoornav_user_manual/installing_backpack_software.mdx
@@ -18,7 +18,7 @@ onto the backpack PC as noted below.
Your IndoorNav backpack PC comes with the latest supported version of
IndoorNav pre-installed. If you need to update or reinstall the software
on the backpack PC, first update the OS using the procedure outlined
-here: .
+here: \.
Once the OS has been updated you will need to connect a monitor,
keyboard, and wired internet connection to backpack PC. Power-on the PC
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/autonomy_api.mdx b/docs_outdoornav_user_manual/api/api_endpoints/autonomy_api.mdx
index b0a6b880f..209218e6f 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/autonomy_api.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/autonomy_api.mdx
@@ -71,18 +71,6 @@ including autonomy state and mode.
**Description:** Current control mode (NEUTRAL, MANUAL, AUTONOMY).
-#### /dock/feedback
-
- **Message Type:** [clearpath_dock_msgs/DockActionFeedback](definitions.mdx#action-dock)
-
- **Description:** Feedback topic from the dock action.
-
-#### /dock/result
-
- **Message Type:** [clearpath_dock_msgs/DockActionResult](definitions.mdx#action-dock)
-
- **Description:** Result topic from the dock action.
-
#### /dock/properties
**Message Type:** [clearpath_dock_msgs/DockProperties](definitions.mdx#msg-dock-properties)
@@ -337,13 +325,13 @@ message for 1 second).
#### /undock/feedback
- **Message Type:** [clearpath_dock_msgs/UndockActionFeedback](definitions.mdx#action-undock)
+ **Message Type:** clearpath_dock_msgs/UndockActionFeedback
**Description:** Feedback topic from the undock action.
#### /undock/result
- **Message Type:** [clearpath_dock_msgs/UndockActionResult](definitions.mdx#action-undock)
+ **Message Type:** clearpath_dock_msgs/UndockActionResult
**Description:** Result topic from the undock action.
@@ -384,7 +372,7 @@ initialized by a previously sent goal.
#### /dock/goal
- **Message Type:** [clearpath_dock_msgs/msg/DockActionGoal](definitions.mdx#action-dock)
+ **Message Type:** clearpath_dock_msgs/msg/DockActionGoal
**Description:** This topic is used to send a goal to the docking process.
The goal consists of the UUID of the dock to dock at as well as wether or not local docking
@@ -399,7 +387,7 @@ initialized by a previously sent goal.
#### /undock/goal
- **Message Type:** [clearpath_dock_msgs/msg/UndockActionGoal](definitions.mdx#action-undock)
+ **Message Type:** clearpath_dock_msgs/msg/UndockActionGoal
**Description:** This topic is used to send a goal to the undocking process.
The goal is empty since we always consider undocking to be a local undocking process.
@@ -445,7 +433,7 @@ or the semantic name of the dock.
#### /dock/clear_data
- **Service Type:** [std_srvs/srv/Trigger](definitions.mdx#srv-clear-dock-data)
+ **Service Type:** std_srvs/srv/Trigger
**Description:** Remove all existing dock data from storage.
@@ -536,7 +524,7 @@ This feature takes effect immediately once the service is called.
:::
-#### /navigation/set_path shifter
+#### /navigation/set_path_shifter
**Service Type:** [clearpath_navigation_msgs/srv/SetPathShifter](definitions.mdx#srv-set-path-shifter)
@@ -627,7 +615,7 @@ goal tolerances, goal heading, an optional start_waypoint_uuid, and a from_start
#### /undock
- **Action Type:** [clearpath_dock_msgs/action/Dock](definitions.mdx#action-undock)
+ **Action Type:** clearpath_dock_msgs/action/Dock
**Description:** Undock the robot to the charging dock, if the docking
package has been included.
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx b/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
index 6abb99c88..fd5cad908 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
@@ -390,7 +390,7 @@ clearpath_navigation_msgs/NetworkMap[] network_maps
clearpath_navigation_msgs/PointOfInterest[] points_of_interest
```
-#### clearpath_mission_scheduler_msgs/msg/NextSchedule.msg
+#### clearpath_mission_scheduler_msgs/msg/NextSchedule.msg {#scheduler-nextschedule}
```
# The ID of the next schedule to start
@@ -401,7 +401,7 @@ string uuid
duration time_to_start
```
-#### clearpath_mission_scheduler_msgs/msg/Schedule {#scheduler-schedule}
+#### clearpath_mission_scheduler_msgs/msg/Schedule.msg {#scheduler-schedule}
```
# Single-execution mode; the schedule starts at the designated time and runs once
@@ -2041,6 +2041,19 @@ bool success
string message
```
+#### clearpath_navigation_msgs/srv/SetPathShifter.srv {#srv-set-path-shifter}
+
+```
+# Service definition to enable/disable the path smoothing feature. If enabling, minimum turning radius must be specified in the request.
+
+bool enable_path_shifter
+float32 path_shift_offset
+float32 path_shift_time
+---
+bool success
+string message
+```
+
#### clearpath_navigation_msgs/srv/SetStopDistance.srv {#srv-set-stop-distance}
```
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/mission_manager_api.mdx b/docs_outdoornav_user_manual/api/api_endpoints/mission_manager_api.mdx
index aaffd47c4..9f2da5321 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/mission_manager_api.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/mission_manager_api.mdx
@@ -134,13 +134,13 @@ In 0.8.0 onward, all missions are required to have unique names. Creating a miss
#### mission_manager/create_network_map
-**Service Type:** [clearpath_mission_manager_msgs/srv/CreateNetworkMap](definitions.mdx#storage-createnetworkmap)
+**Service Type:** clearpath_mission_manager_msgs/srv/CreateNetworkMap
**Description:** Create a new network of paths map
#### mission_manager/create_network_mission
-**Service Type:** [clearpath_mission_manager_msgs/srv/CreateNetworkMission](definitions.mdx#storage-createnetworkmission)
+**Service Type:** clearpath_mission_manager_msgs/srv/CreateNetworkMission
**Description:** Create a new network of paths mission
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/mission_scheduler_api.mdx b/docs_outdoornav_user_manual/api/api_endpoints/mission_scheduler_api.mdx
index 80a30da1c..13e0027a4 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/mission_scheduler_api.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/mission_scheduler_api.mdx
@@ -100,7 +100,7 @@ This action is permanent and cannot be undone. Use with caution.
### mission_scheduler/enable_schedule
-**Service Type:** [mission_scheduler/srv/UpdateSchedule](definitions.mdx#scheduler-enablechedule)
+**Service Type:** [mission_scheduler/srv/UpdateSchedule](definitions.mdx#scheduler-enableschedule)
**Description:** Enable or disable a schedule.
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/platform_api.mdx b/docs_outdoornav_user_manual/api/api_endpoints/platform_api.mdx
index c2ce5b11c..ea8a0c163 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/platform_api.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/platform_api.mdx
@@ -108,7 +108,7 @@ integrated onto our robot platforms.
**Description:** Reports the MPU 9250 Magnetometer sensor information.
-#### /sensors/_\[0,1,\...\]/fix
+#### /sensors/\_\[0,1,\...\]/fix
**Message Type:** sensor_msgs/NavSatFix
@@ -117,7 +117,7 @@ integrated onto our robot platforms.
**Description:** GPS latitude and longitude data. This data can either
be RTK corrected or regular GPS data.
-#### /sensors/_[0,1,\...\]/heading
+#### /sensors/\_[0,1,\...\]/heading
**Message Type:** sensor_msgs/Imu
@@ -126,7 +126,7 @@ be RTK corrected or regular GPS data.
**Description:** RTK heading data computed from a dual GPS receiver
setup.
-#### /sensors/_\[0,1,\...\]/pointcloud
+#### /sensors/\_\[0,1,\...\]/pointcloud
**Message Type:** Type: sensor_msgs/PointCloud2
@@ -134,7 +134,7 @@ setup.
**Description:** Raw pointcloud data generated from the specific sensor.
-#### /sensors/_\[0,1,\...\]/scan
+#### /sensors/\_\[0,1,\...\]/scan
**Message Type:** sensor_msgs/LaserScan
@@ -142,7 +142,7 @@ setup.
**Description:** Raw scan data generated from the specific sensor.
-#### /sensors/_\[0,1,\...\]/camera_info
+#### /sensors/\_\[0,1,\...\]/camera_info
**Message Type:** sensor_msgs/CameraInfo
@@ -151,7 +151,7 @@ setup.
**Description:** Camera information including image dimensions,
distortion parameters, calibration parameters, etc\...
-#### /sensors/_\[0,1,\...\]/image
+#### /sensors/\_\[0,1,\...\]/image
**Message Type:** sensor_msgs/Image
@@ -159,7 +159,7 @@ distortion parameters, calibration parameters, etc\...
**Description:** Image data from the specific sensor.
-#### /sensors/_\[0,1,\...\]/depth/camera_info
+#### /sensors/\_\[0,1,\...\]/depth/camera_info
**Message Type:** sensor_msgs/CameraInfo
@@ -168,7 +168,7 @@ distortion parameters, calibration parameters, etc\...
**Description:** Camera information for the depth image including image dimensions,
distortion parameters, calibration parameters, etc\...
-#### /sensors/_\[0,1,\...\]/depth/image_rect_raw
+#### /sensors/\_\[0,1,\...\]/depth/image_rect_raw
**Message Type:** sensor_msgs/Image
diff --git a/docs_outdoornav_user_manual/customized_tuning/sensor_customization.mdx b/docs_outdoornav_user_manual/customized_tuning/sensor_customization.mdx
index 3839162fd..9d9f115aa 100644
--- a/docs_outdoornav_user_manual/customized_tuning/sensor_customization.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/sensor_customization.mdx
@@ -6,4 +6,4 @@ toc_min_heading_level: 2
toc_max_heading_level: 4
---
-Information incoming in a future release. Please contact Clearpath customer support at to discuss any related issue.
+Information incoming in a future release. Please contact Clearpath customer support at \ to discuss any related issue.
diff --git a/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/differential_drive_dynamics.mdx b/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/differential_drive_dynamics.mdx
index ba6ee960a..0b852a922 100644
--- a/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/differential_drive_dynamics.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/differential_drive_dynamics.mdx
@@ -371,7 +371,7 @@ following parameters:
No available solutions yet to resolve oscillations due to causes \#3 and \#4. Please contact
-Clearpath customer support at to discuss any related issue.
+Clearpath customer support at \ to discuss any related issue.
#### Increase Linear Velocity {#increase_linear_velocity}
@@ -383,12 +383,12 @@ To increase the UGVs maximum velocity, the following parameters should be modifi
First, the [`mpc_horizon`](../tuning_parameters/navigation_parameters.mdx#default_state_params) parameter
should be set to: 1.0
-The following parameters should then be modified to the desired velocity ($v_{des}$). Ie. if $v_{des}=4.0$ m/s, then you should modify both parameters to be 4.0.
+The following parameters should then be modified to the desired velocity ($v_\{des\}$). Ie. if $v_\{des\}=4.0$ m/s, then you should modify both parameters to be 4.0.
| Parameter | Value |
|-----------|-------|
-| [`max_fwd_velocity`](../tuning_parameters/navigation_parameters.mdx#default_state_params) | $v_{des}$ |
-| [`max_lookahead`](../tuning_parameters/navigation_parameters.mdx#default_state_params) | $v_{des}$ |
+| [`max_fwd_velocity`](../tuning_parameters/navigation_parameters.mdx#default_state_params) | $v_\{des\}$ |
+| [`max_lookahead`](../tuning_parameters/navigation_parameters.mdx#default_state_params) | $v_\{des\}$ |
Finally, if you are increasing the velocity to a value greater than or equal to 4.0 m/s or if you
are seeing that the velocity is being limited even after changing the above parameters,
@@ -564,7 +564,7 @@ costmap size. Increase the costmap using these parameters:
| Parameter | Default |
|-----------|---------|
-| [`local_costmap/width`](../tuning_parameters/collision_avoidance_parameters.mdx#costmap_params) | $2 * l_{max\_footprint} + 0.5$ |
-| [`local_costmap/height`](../tuning_parameters/collision_avoidance_parameters.mdx#costmap_params) | $2 * l_{max\_footprint} + 0.5$ |
+| [`local_costmap/width`](../tuning_parameters/collision_avoidance_parameters.mdx#costmap_params) | $2 * l_\{max\_footprint\} + 0.5$ |
+| [`local_costmap/height`](../tuning_parameters/collision_avoidance_parameters.mdx#costmap_params) | $2 * l_\{max\_footprint\} + 0.5$ |
-where l_{max\_footprint} is the length of the largest safety footprint.
+where l_\{max\_footprint\} is the length of the largest safety footprint.
diff --git a/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/footprint_tuning.mdx b/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/footprint_tuning.mdx
index a36d1b853..4b90f6008 100644
--- a/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/footprint_tuning.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/tuning_instructions/footprint_tuning.mdx
@@ -6,4 +6,4 @@ toc_min_heading_level: 2
toc_max_heading_level: 2
---
-Information incoming in release 0.9.0. Please contact Clearpath customer support at to discuss any related issue.
+Information incoming in release 0.9.0. Please contact Clearpath customer support at \ to discuss any related issue.
diff --git a/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/localization_parameters.mdx b/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/localization_parameters.mdx
index b8102c74d..a6e567ca7 100644
--- a/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/localization_parameters.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/localization_parameters.mdx
@@ -6,4 +6,4 @@ toc_min_heading_level: 2
toc_max_heading_level: 3
---
-Information incoming in release 0.9. Please contact Clearpath customer support at to discuss the issue.
+Information incoming in release 0.9. Please contact Clearpath customer support at \ to discuss the issue.
diff --git a/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/navigation_parameters.mdx b/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/navigation_parameters.mdx
index fa47f2248..b88562a4b 100644
--- a/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/navigation_parameters.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/tuning_parameters/navigation_parameters.mdx
@@ -166,4 +166,4 @@ The following parameters can be used to set a specific stop distance away from o
## Path Planners {#path_planners}
-Information incoming in release 0.9. Please contact Clearpath customer support at to discuss the issue.
+Information incoming in release 0.9. Please contact Clearpath customer support at \ to discuss the issue.
diff --git a/docs_outdoornav_user_manual/customized_tuning/user_interface_customization.mdx b/docs_outdoornav_user_manual/customized_tuning/user_interface_customization.mdx
index 17c27a3f0..c67bca22a 100644
--- a/docs_outdoornav_user_manual/customized_tuning/user_interface_customization.mdx
+++ b/docs_outdoornav_user_manual/customized_tuning/user_interface_customization.mdx
@@ -6,4 +6,4 @@ toc_min_heading_level: 2
toc_max_heading_level: 4
---
-Information incoming in a future release. Please contact Clearpath customer support at to discuss any related issue.
+Information incoming in a future release. Please contact Clearpath customer support at \ to discuss any related issue.
diff --git a/docs_outdoornav_user_manual/features/collision_avoidance.mdx b/docs_outdoornav_user_manual/features/collision_avoidance.mdx
index bec48f5f3..777148fab 100644
--- a/docs_outdoornav_user_manual/features/collision_avoidance.mdx
+++ b/docs_outdoornav_user_manual/features/collision_avoidance.mdx
@@ -98,7 +98,7 @@ Eg. Velodyne, Ouster or Realsense
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_FILTER_VOXEL** | Enable/disable the PCL voxel filter for the sensor of type .
type = {VLP, D435, REAR_VLP, REAR_D435} | bool (false) |
+| **\_ENABLE_FILTER_VOXEL** | Enable/disable the PCL voxel filter for the sensor of type \.
type = \{VLP, D435, REAR_VLP, REAR_D435\} | bool (false) |
| **PCL_FIL_FILTER_VOXEL_LEAF_SIZE** | The size of a leaf (on x,y,z), in meters, used for downsampling. Range: 0.0 to 1.0. | double (0.01) |
#### Cropbox Filter
@@ -110,7 +110,7 @@ Eg. Velodyne, Ouster or Realsense
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_FILTER_CROPBOX** | Enable/disable the PCL cropbox filter for the sensor of type .
type = {VLP, D435, REAR_VLP, REAR_D435} | bool (false) |
+| **\_ENABLE_FILTER_CROPBOX** | Enable/disable the PCL cropbox filter for the sensor of type \.
type = \{VLP, D435, REAR_VLP, REAR_D435\} | bool (false) |
| **PCL_FILTER_CROPBOX_MIN_X** | The lower bound, in meters, on the x-axis within which to reject points from the pointcloud. Range: -1000.0 to 1000.0. | double (0.01) |
| **PCL_FILTER_CROPBOX_MAX_X** | The upper bound, in meters, on the x-axis within which to reject points from the pointcloud. Range: -1000.0 to 1000.0. | double (2.0) |
| **PCL_FILTER_CROPBOX_MIN_Y** | The lower bound, in meters, on the y-axis within which to reject points from the pointcloud. Range: -1000.0 to 1000.0. | double (-10.0) |
@@ -127,7 +127,7 @@ Eg. Velodyne, Ouster or Realsense
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_FILTER_RADIUS_OUTLIER** | Enable/disable the PCL radius outlier filter for the sensor of type .
type = {VLP, D435, REAR_VLP, REAR_D435} | bool (false) |
+| **\_ENABLE_FILTER_RADIUS_OUTLIER** | Enable/disable the PCL radius outlier filter for the sensor of type \.
type = \{VLP, D435, REAR_VLP, REAR_D435\} | bool (false) |
| **PCL_FILTER_ROR_RADIUS_SEARCH** | The number of points within this distance, in meters, from the query point will need to be equal or greater than PCL_FILTER_ROR_MIN_NEIGHBORS in order to be classified as an inlier point (i.e. will not be filtered). | double (0.05) |
| **PCL_FILTER_ROR_MIN_NEIGHBORS** | The number of points within PCL_FILTER_ROR_RADIUS_SEARCH from the query point will need to be equal or greater than this number in order to be classified as an inlier point (i.e. will not be filtered). | int (10) |
@@ -140,7 +140,7 @@ Eg. Velodyne, Ouster or Realsense
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_FILTER_STATISTICAL_OUTLIER** | Enable/disable the PCL statistical outlier filter for the sensor of type .
type = {VLP, D435, REAR_VLP, REAR_D435} | bool (false) |
+| **\_ENABLE_FILTER_STATISTICAL_OUTLIER** | Enable/disable the PCL statistical outlier filter for the sensor of type \.
type = \{VLP, D435, REAR_VLP, REAR_D435\} | bool (false) |
| **PCL_FILTER_SOR_MEAN_K** | The number of points (k) to use for mean distance estimation Range: 2 to 100. | double (5.0) |
| **PCL_FILTER_SOR_STD_DEV** | The standard deviation multiplier threshold. All points outside the mean +- sigma * std_mul will be considered outliers. Range: 0.0 to 5.0. | double (0.3) |
@@ -150,7 +150,7 @@ The following filter is enabled by default and is applied after any 3D LiDAR fil
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_POINTCLOUD_TO_LASERSCAN** | Enable/disable the pointcloud to laserscan outlier filter for the sensor of type .
type = {VLP, D435, REAR_VLP, REAR_D435} | bool (false) |
+| **\_ENABLE_POINTCLOUD_TO_LASERSCAN** | Enable/disable the pointcloud to laserscan outlier filter for the sensor of type \.
type = \{VLP, D435, REAR_VLP, REAR_D435\} | bool (false) |
| **PCL_TO_SCAN_MIN_HEIGHT** | The minimum height to sample in the point cloud, in meters. | double (0.2) |
| **PCL_TO_SCAN_MAX_HEIGHT** | The maximum height to sample in the point cloud, in meters. | double (1.2) |
| **PCL_TO_SCAN_MIN_ANGLE** | The minimum scan angle, in radians. | double (3.14) |
@@ -169,7 +169,7 @@ Eg. Realsense [`DepthImage`](http://docs.ros.org/en/noetic/api/sensor_msgs/html/
| Environment Variable | Description | Data Type (Default) |
|----------------------|------------------------------------------|---------------------|
-| **_ENABLE_DEPTH_TO_LASERSCAN** | Enable/disable the depth image to laserscan outlier filter for the sensor of type .
type = {D435, REAR_D435} | bool (false) |
+| **\_ENABLE_DEPTH_TO_LASERSCAN** | Enable/disable the depth image to laserscan outlier filter for the sensor of type \.
type = \{D435, REAR_D435\} | bool (false) |
| **DEPTH_TO_SCAN_HEIGHT** | The number of pixel rows to use to generate the laserscan. For each column, the scan will return the minimum value for those pixels centered vertically in the image. | int |
| **DEPTH_TO_SCAN_TIME** | Time between scans (seconds). Typically, 1.0/frame_rate. This value is not easily calculated from consecutive messages, and is thus left to the user to set correctly. | double |
| **DEPTH_TO_SCAN_MIN_RANGE** | The minimum ranges to return in meters. Ranges less than this will be output as -Inf. | double |
@@ -211,10 +211,10 @@ attempting to modify these parameters.
| Environment Variable | Description | Data Type |
|----------------------|------------------------------------------|-----------|
-| **COSTMAP\_LIDAR\_<2D/3D\>_OBSTACLE_RANGE** | The maximum range in meters at which to insert obstacles into the costmap using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
-| **COSTMAP\_LIDAR\_<2D/3D\>_RAYTRACE_RANGE** | The maximum range in meters at which to raytrace out obstacles from the map using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
-| **COSTMAP\_REAR_LIDAR\_<2D/3D\>_OBSTACLE_RANGE** | The maximum range in meters at which to insert obstacles into the costmap using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (rear unit if more than one). | double |
-| **COSTMAP\_REAR_LIDAR\_<2D/3D\>_RAYTRACE_RANGE** | The maximum range in meters at which to raytrace out obstacles from the map using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
+| **COSTMAP\_LIDAR\_\<2D/3D\>_OBSTACLE_RANGE** | The maximum range in meters at which to insert obstacles into the costmap using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
+| **COSTMAP\_LIDAR\_\<2D/3D\>_RAYTRACE_RANGE** | The maximum range in meters at which to raytrace out obstacles from the map using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
+| **COSTMAP\_REAR_LIDAR\_\<2D/3D\>_OBSTACLE_RANGE** | The maximum range in meters at which to insert obstacles into the costmap using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (rear unit if more than one). | double |
+| **COSTMAP\_REAR_LIDAR\_\<2D/3D\>_RAYTRACE_RANGE** | The maximum range in meters at which to raytrace out obstacles from the map using sensor data. This can apply for either 2D or 3D variables, associated with 2D and 3D lidars, respectively (front unit if more than one). | double |
## Limitations
diff --git a/docs_outdoornav_user_manual/features/custom_tasks.mdx b/docs_outdoornav_user_manual/features/custom_tasks.mdx
index 5ecbb813b..5b1176997 100644
--- a/docs_outdoornav_user_manual/features/custom_tasks.mdx
+++ b/docs_outdoornav_user_manual/features/custom_tasks.mdx
@@ -8,7 +8,7 @@ toc_max_heading_level: 4
Users can create their custom tasks for their application following a specific template.
When creating these tasks, the user should begin by creating a python file in the
-**/opt/onav//app/custom_tasks/** directory, where *onav_version*
+**/opt/onav/\/app/custom_tasks/** directory, where *onav_version*
is the currently running version of OutdoorNav. The file should be written following
the instructions provided below:
diff --git a/docs_outdoornav_user_manual/getting_started/tf_validation.mdx b/docs_outdoornav_user_manual/getting_started/tf_validation.mdx
index 5ba3bab49..72327dbc3 100644
--- a/docs_outdoornav_user_manual/getting_started/tf_validation.mdx
+++ b/docs_outdoornav_user_manual/getting_started/tf_validation.mdx
@@ -26,7 +26,7 @@ green (pointing towards the left of the UGV) and Z in blue (pointing
towards the sky).
You can check the current value of the environment variables by running
-the following on the robot (host) computer (and setting
+the following on the robot (host) computer (and setting \
to the names listed in the table below).
``` bash
diff --git a/docs_outdoornav_user_manual/integration_requirements/interface_control_requirements.mdx b/docs_outdoornav_user_manual/integration_requirements/interface_control_requirements.mdx
index 45cdfb2c4..a603485bb 100644
--- a/docs_outdoornav_user_manual/integration_requirements/interface_control_requirements.mdx
+++ b/docs_outdoornav_user_manual/integration_requirements/interface_control_requirements.mdx
@@ -83,10 +83,10 @@ z: ___"
```
The three trials that we request will vary between platforms depending
-on the its maximum linear $(v_{max})$ and angular velocities
-$(\omega_{max})$, minimum linear $(v_{min})$ and angular velocities
-$(\omega_{min})$, as well as limitations due to the minimum allowable
-turning radius $(r_{min})$. Of these three trials, we would like to see
+on the its maximum linear $(v_\{max\})$ and angular velocities
+$(\omega_\{max\})$, minimum linear $(v_\{min\})$ and angular velocities
+$(\omega_\{min\})$, as well as limitations due to the minimum allowable
+turning radius $(r_\{min\})$. Of these three trials, we would like to see
data within three linear velocity bands, as seen in the table below,
resulting in three different turning radii. For the purpose of these
tests, the following formula can be used when determining the required
@@ -94,11 +94,11 @@ linear and angular velocities to apply: $r = v/\omega$.
| Trial \# | Linear X Bands \[m/s\] | Example Linear X Band \[m/s\] |
| ---------|--------------------------------------------|-------------------------------------|
-| 1 | $v_{min} \cdot [1.0, 1.5]$ | $[0.5, 0.75]$ |
-| 2 | $((v_{max} - v_{min})/2) \cdot [0.9, 1.1]$ | $[2.025, 2.475]$ |
-| 3 | $v_{max} \cdot [0.9, 1.0]$ | $[4.5, 5.0]$ |
+| 1 | $v_\{min\} \cdot [1.0, 1.5]$ | $[0.5, 0.75]$ |
+| 2 | $((v_\{max\} - v_\{min\})/2) \cdot [0.9, 1.1]$ | $[2.025, 2.475]$ |
+| 3 | $v_\{max\} \cdot [0.9, 1.0]$ | $[4.5, 5.0]$ |
-As an example, a platform with specs $v \in [0.5, 5.0]$, $r_{min} = 3$
+As an example, a platform with specs $v \in [0.5, 5.0]$, $r_\{min\} = 3$
would have linear x velocity bands as listed in the table above. The
trials could then be as outlined in the table below.
diff --git a/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx b/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx
index 8784aa297..1580491e5 100644
--- a/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx
+++ b/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx
@@ -129,7 +129,7 @@ rostopic echo -n 1 /sensors/stereo_1/image --noarr
rostopic echo -n 1 /sensors/stereo_1/depth/image_rect_raw --noarr
```
- will be the number of the sensor as it was loaded into the software. Eg. If you have a VLP and an LMS1XX, then the VLP will be lidar_0, and the LMS1XX will be lidar_1. If we only have an LMS1XX, then it would be lidar_0. Ie. the 3D lidars have a higher "priority" and therefore will be loaded first.
+\ will be the number of the sensor as it was loaded into the software. Eg. If you have a VLP and an LMS1XX, then the VLP will be lidar_0, and the LMS1XX will be lidar_1. If we only have an LMS1XX, then it would be lidar_0. Ie. the 3D lidars have a higher "priority" and therefore will be loaded first.
:::note
diff --git a/docs_outdoornav_user_manual/overview/overview_scope.mdx b/docs_outdoornav_user_manual/overview/overview_scope.mdx
index 13f8b9af1..ba0092f1c 100644
--- a/docs_outdoornav_user_manual/overview/overview_scope.mdx
+++ b/docs_outdoornav_user_manual/overview/overview_scope.mdx
@@ -9,7 +9,7 @@ toc_max_heading_level: 4
This documentation focuses on the OutdoorNav Software itself, including
hardware dependencies and integration, but not the specifics of UGV
hardware. For details on compatible Clearpath Robotics UGVs and custom
-hardware integrations, contact or check
+hardware integrations, contact \ or check
out our [YouTube channel](https://www.youtube.com/channel/UCNPP3C-ZK3mwpG2x89VE-2Q).
diff --git a/docs_outdoornav_user_manual/tools/foxglove_visualization.mdx b/docs_outdoornav_user_manual/tools/foxglove_visualization.mdx
index f71a426b0..20bd92683 100644
--- a/docs_outdoornav_user_manual/tools/foxglove_visualization.mdx
+++ b/docs_outdoornav_user_manual/tools/foxglove_visualization.mdx
@@ -12,7 +12,7 @@ standard OutdoorNav configurations, access the **Menu** → **Tools** &srarr
**Foxglove Visualization** or navigate to the following [URL](http://192.168.131.1/_/foxglove).
For UGVs running OutdoorNav that are not equipped with a base station, you must first connect the UGV's computer to a network over the 192.168.131.xxx
-subnet. You will then be able to access the platform at (`platform_pc_ip_address`/\_/foxglove), where the __ is
+subnet. You will then be able to access the platform at (`platform_pc_ip_address`/\_/foxglove), where the _\_ is
the IP address of the host (UGV) computer, typically 192.168.131.1.
diff --git a/docs_outdoornav_user_manual/web_user_interface/ui_overview.mdx b/docs_outdoornav_user_manual/web_user_interface/ui_overview.mdx
index 252e329cc..b1484c034 100644
--- a/docs_outdoornav_user_manual/web_user_interface/ui_overview.mdx
+++ b/docs_outdoornav_user_manual/web_user_interface/ui_overview.mdx
@@ -437,7 +437,7 @@ by using the steps below.
4. Select **Custom**.
5. Enter the network path for the maps into the **Custom URL** field.
If hosting the maps on your local computer, this will be similar to
- . Note how the
+ http://localhost:8000/{z}/{x}/{-y}.png. Note how the
URL is parameterized with `{z}`, `{x}`, and `{-y}` values. This will
need to be adapted to match the directory structure of your map tile
images.
@@ -488,7 +488,7 @@ below.
5. Use a web server to host the tiles locally. Using Ubuntu, one way to
accomplish this is to use the commands below, which will make the
- tiles available at: .
+ tiles available at: \.
```
cd /base/directory/of/tiles
diff --git a/docs_versioned_docs/version-ros1noetic/components/_remote_ros_connectivity.mdx b/docs_versioned_docs/version-ros1noetic/components/_remote_ros_connectivity.mdx
index e0d7e544f..ef18c28ef 100644
--- a/docs_versioned_docs/version-ros1noetic/components/_remote_ros_connectivity.mdx
+++ b/docs_versioned_docs/version-ros1noetic/components/_remote_ros_connectivity.mdx
@@ -52,5 +52,5 @@ You can also run the RViz commands outlined in the Tutorials.
If the tools launch, then everything is setup properly. If you still need assistance
in configuring remote access, please contact Clearpath Support. For more general details on how ROS works over TCP with
-multiple machines, please see: . For help troubleshooting a multiple
-machines connectivity issue, see: .
+multiple machines, please see: http://wiki.ros.org/ROS/Tutorials/MultipleMachines. For help troubleshooting a multiple
+machines connectivity issue, see: http://wiki.ros.org/ROS/NetworkSetup.
diff --git a/docs_versioned_docs/version-ros1noetic/components/_support_introduction.mdx b/docs_versioned_docs/version-ros1noetic/components/_support_introduction.mdx
index 8b3a19730..8dae5ac90 100644
--- a/docs_versioned_docs/version-ros1noetic/components/_support_introduction.mdx
+++ b/docs_versioned_docs/version-ros1noetic/components/_support_introduction.mdx
@@ -1,6 +1,6 @@
Robots are complex.
Common issues are listed below.
-Contact our support team at if the issue persists.
+Contact our support team at \ if the issue persists.
:::info
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/add-ons.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/add-ons.mdx
index 9e992ffdc..946cf0251 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/add-ons.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/add-ons.mdx
@@ -31,5 +31,5 @@ Thses pages will list subsystems like:
We suggest you:
1. Review our documentation of these accessories.
-2. If you want Clearpath Robotics to integrate accessories on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-3. Contact our Support team at if you have any questions.
+2. If you want Clearpath Robotics to integrate accessories on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+3. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/din_rail.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/din_rail.mdx
index 748b70ff0..235b8e2fc 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/din_rail.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/add-ons/din_rail.mdx
@@ -22,46 +22,49 @@ sidebar_position: 4
## DIN Rail Lengths
-Click to expand
+
## Common Parts
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/computers/mini_itx.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/computers/mini_itx.mdx
index 298b8c750..de36dfdf4 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/computers/mini_itx.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/computers/mini_itx.mdx
@@ -17,14 +17,14 @@ on the individual robot pages, such as the
:::note
If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team
-at , whether you want to use a new Clearpath Robotics platform,
+at \, whether you want to use a new Clearpath Robotics platform,
or reuse your existing vehicle.
:::
:::note
-Contact our Support team at if you have any questions.
+Contact our Support team at \ if you have any questions.
:::
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/manipulators/manipulators.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/manipulators/manipulators.mdx
index 8171ee632..62e08fcf2 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/manipulators/manipulators.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/manipulators/manipulators.mdx
@@ -28,5 +28,5 @@ We suggest you:
1. Review our documentation of the manipulators related to your robot integration.
2. Review the related Further Reading section.
3. If you are planning to purchase a manipulator, consider visiting our [Component Store](https://store.clearpathrobotics.com/).
-4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-5. Contact our Support team at if you have any questions.
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/sensors.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/sensors.mdx
index b5670730d..ec123e019 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/sensors.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/sensors.mdx
@@ -28,5 +28,5 @@ We suggest you:
1. Review our documentation of the sensors related to your robot integration.
2. Review the related _Further Reading_ section.
3. If you are planning to purchase a sensor for standalone use, or for integration with a non-Clearpath system, consider visiting our Component Store, [store.clearpathrobotics.com](https://store.clearpathrobotics.com/).
-4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-5. Contact our Support team at if you have any questions.
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/common/physical_tools.mdx b/docs_versioned_docs/version-ros1noetic/robots/common/physical_tools.mdx
index 11af92caf..84f14e462 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/common/physical_tools.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/common/physical_tools.mdx
@@ -9,7 +9,7 @@ The intention of this page is to show you what tools we use for maintenance, and
:::info Contact Us
-Contact our Sales team at if you want us to add sensors or custom attachments to your robot.
+Contact our Sales team at \ if you want us to add sensors or custom attachments to your robot.
We can suggest hardware and software that will meet your application goals.
You can see some of our past Integration Services projects [here](https://clearpathrobotics.com/integration-services/).
diff --git a/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/boxer/user_manual_boxer.mdx b/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/boxer/user_manual_boxer.mdx
index 38aa044af..69d8e651d 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/boxer/user_manual_boxer.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/boxer/user_manual_boxer.mdx
@@ -230,7 +230,7 @@ Connect the Boxer to the Wi-Fi network using the steps below.
Refer to [Connecting to a robot using an Ethernet cable](https://docs.ottomotors.com/en/30495-30527-connecting-to-a-robot-using-ethernet.html) and
[Connecting a robot to a network](https://docs.ottomotors.com/en/30495-30526-connecting-a-robot-to-a-network.html) for more details.
-1. Configure a network port on your laptop with the IP address <10.255.255.200>.
+1. Configure a network port on your laptop with the IP address \<10.255.255.200\>.
2. Connect a network cable from the port on your laptop to the network port on the rear of the Base Unit.
-3. On your laptop, open a web-browser like Google Chrome, and go to the address
+3. On your laptop, open a web-browser like Google Chrome, and go to the address http://10.255.255.1:8090
4. Enter the required information to connect to your network.
See your IT administrator for proper settings for your network.
@@ -285,7 +285,7 @@ The Backpack Computer is an add-on computer that is networked with the Base Unit
This Backpack Computer can be used to integrate peripherals, like sensors and manipulators.
A ROS bridge automatically runs upon booting the Backpack Computer, and transmits the Base Unit computer's ROS data to the Backpack Computer.
This ROS bridge allows you to leverage the Base Unit for your own application.
-The Backpack Computer uses Netplan as its network configuration tool, and has a static IP address of <192.168.131.1>.
+The Backpack Computer uses Netplan as its network configuration tool, and has a static IP address of \<192.168.131.1\>.
#### Connecting to the Backpack Computer
@@ -293,7 +293,7 @@ You can connect to the Backpack Computer on Boxer over a wired or Wi-Fi connecti
To connect to the Backpack Computer over a wired connection:
-1. Configure a network port on your laptop with the IP address <192.168.131.100>.
+1. Configure a network port on your laptop with the IP address \<192.168.131.100\>.
2. Connect a network cable from your laptop to an open network port on the Backpack Computer.
3. Test the connection between the user computer and Backpack Computer by opening a terminal and entering: `ping 192.168.131.1 `
4. From your laptop's terminal, you can access the Backpack Computer by entering: `ssh administrator@192.168.131.1`
@@ -393,7 +393,7 @@ This section details how to get the Robot driving around using the OTTO user int
3. Using the base Boxer's hostname or static IP, open the OTTO App by entering the following in your laptop's web-browser:
- http://:5000
+ http://\:5000
4. You are now ready to start driving your system.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/dingo/user_manual_dingo.mdx b/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/dingo/user_manual_dingo.mdx
index 36b2cf66b..8856fe0fa 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/dingo/user_manual_dingo.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/indoor_robots/dingo/user_manual_dingo.mdx
@@ -539,11 +539,12 @@ The batteries are rugged and designed for the demanding environments into which
label="Dingo 1.5"
default
>
-For Dingo 1.5, to charge the batteries, simply connect the manual charger to the charge port on the front of the Dingo. Charging can take place while the unit is powered,
-or unpowered, or while the unit is connected to DC Shore Power. The charging current for the SLA system is 6A, and 7A for the LiFEPO4 system. Care must be
-taken when charging while the system is powered, as if the load/total current is higher than the supplied charge current the batteries will continue to drain.
-If the total system current is less than the charge current the batteries will charge, but at a reduced rate as the system will be using a portion of the
-charger current to maintain operation.
+ For Dingo 1.5, to charge the batteries, simply connect the manual charger to the charge port on the front of the Dingo. Charging can take place while the unit is powered,
+ or unpowered, or while the unit is connected to DC Shore Power. The charging current for the SLA system is 6A, and 7A for the LiFEPO4 system. Care must be
+ taken when charging while the system is powered, as if the load/total current is higher than the supplied charge current the batteries will continue to drain.
+ If the total system current is less than the charge current the batteries will charge, but at a reduced rate as the system will be using a portion of the
+ charger current to maintain operation.
+
For multi-battery systems the charge current is distributed across the number of batteries present in the system, so charging time will increase appropriately.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/maintenance_husky.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/maintenance_husky.mdx
index 94af8abf0..761a86a01 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/maintenance_husky.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/maintenance_husky.mdx
@@ -200,41 +200,42 @@ The [Common Replacement Items](#husky_maintenance_common_replacement_items) sect
:::
-Click to expand
-
-
-
-
- Husky's rear battery access
-
-
-
-
-
-
-
-
- User power fuses
-
-
-
-
-
-
-
-
- Main battery fuse
-
-
+
+ Click to expand
+
+
+
+
+ Husky's rear battery access
+
+
+
+
+
+
+
+
+ User power fuses
+
+
+
+
+
+
+
+
+ Main battery fuse
+
+
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/troubleshooting_husky.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/troubleshooting_husky.mdx
index 614494928..e13214932 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/troubleshooting_husky.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/troubleshooting_husky.mdx
@@ -136,7 +136,7 @@ There is no way to change this behaviour on your Husky.
It's possible the robot has reached the thermal limit, or current limit.
The maximum current limits are set to 26 A, however, as the motors are only rated for 10.7 A continuous, anything above that will trigger the current limit eventually, the higher above this limit, the more quickly it will trigger.
-If you are unsure whether this is the case, feel free to contact with a rosbag of your system.
+If you are unsure whether this is the case, feel free to contact \ with a rosbag of your system.
:::note
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/tutorials_husky.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/tutorials_husky.mdx
index 0a559a76a..c69fbc3c5 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/tutorials_husky.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/tutorials_husky.mdx
@@ -111,7 +111,7 @@ The most important nodes are summarized in the following table.
| `/robot_state_publisher` | Subscribes to `/joint_states` and publishes the robot's state to `/tf` |
| `/bluetooth_teleop` | Publishes velocity commands from a joystick to `/twist_mux` |
| `/twist_mux` | Takes in multiple sources of velocity commands, and prioritizes what actually gets sent to the controller |
-| `/ekf_localization` | Part of the robot localization package, more information regarding this package can be found at |
+| `/ekf_localization` | Part of the robot localization package, more information regarding this package can be found at http://wiki.ros.org/robot_localization |
#### Topics
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/user_manual_husky.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/user_manual_husky.mdx
index c2ddf2df6..f74792cda 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/user_manual_husky.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/user_manual_husky.mdx
@@ -128,7 +128,7 @@ $$
$$
$v$ represents the instantaneous translational speed of the platform and $\omega$ the instantaneous rotational speed.
-$v_{r}$ and $v_{l}$ are the right and left wheel velocities, respectively.
+$v_\{r\}$ and $v_\{l\}$ are the right and left wheel velocities, respectively.
$W$ is the effective track of the robot, 0.555 m.
### System Specifications
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/jackal/tutorials_jackal.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/jackal/tutorials_jackal.mdx
index b9a0b05de..09ef3a169 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/jackal/tutorials_jackal.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/jackal/tutorials_jackal.mdx
@@ -696,7 +696,7 @@ When RViz appears, select the _Set 2D Pose tool_ from the toolbar, and click on
---
-## Jackal Tests
+## Jackal Tests {#testing-jackal}
Jackal robots come preinstalled with a set of test scripts as part of the `jackal_tests` ROS package, which can be run to verify robot functionality at the component and system levels.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
index beadab449..8aacdf691 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
@@ -25,7 +25,7 @@ You can attach your own custom brakets to the extrusions using M5×0.8 T-slot nu
Misumi also offers a range of configurable products that can help with your integration.
-Please email if you want Clearpath's team to design a bracket structure for your application.
+Please email \ if you want Clearpath's team to design a bracket structure for your application.
---
diff --git a/docs_versioned_docs/version-ros1noetic/robots/robots.mdx b/docs_versioned_docs/version-ros1noetic/robots/robots.mdx
index 8980dc9aa..a15443781 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/robots.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/robots.mdx
@@ -29,7 +29,7 @@ The extensibility of ROS has also allowed Clearpath to use it to develop the pro
1. Review the documentation for our robot platforms, sensors, add-ons, and autonomy software.
2. Try some of our tutorials. Some of these tutorials use a simulated robot, so you can try developing with ROS before purchasing hardware.
3. Review some of our [GitHub](https://github.com/clearpathrobotics) repositories.
-4. Discuss your application with our Sales team at , whether you already have a robot or not.
+4. Discuss your application with our Sales team at \, whether you already have a robot or not.
:::
diff --git a/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/maintenance_husky_observer.mdx b/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/maintenance_husky_observer.mdx
index 50800fb85..4543742b5 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/maintenance_husky_observer.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/maintenance_husky_observer.mdx
@@ -24,10 +24,10 @@ noting that the robot will only charge on the dock when the disconnect is in the
- Manually drive the robot to its position at the dock. The receiver on
the robot should be properly aligned with the circle on the dock transmitter.
- Use the OutdoorNav UI to dock the robot autonomously. Please consult
- [Autonomous Missions](#autonomous-missions) for further details.
- This method requires that the [base station has been surveyed](#survey-base-station),
- the [Datum has been set to the coordinates of the test site](#set-datum),
- and that the [dock location has been set](#set-dock-location).
+ [Autonomous Missions](user_manual_husky_observer#autonomous-missions) for further details.
+ This method requires that the [base station has been surveyed](user_manual_husky_observer#survey-base-station),
+ the [Datum has been set to the coordinates of the test site](user_manual_husky_observer#set-datum),
+ and that the [dock location has been set](user_manual_husky_observer#set-dock-location).
:::note
diff --git a/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/user_manual_husky_observer.mdx b/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/user_manual_husky_observer.mdx
index 068b4f3c4..667ca830e 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/user_manual_husky_observer.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/solutions/husky_observer/user_manual_husky_observer.mdx
@@ -889,7 +889,7 @@ modes for deploying Husky Observer, which are outlined below.
| Network Mode | Description | Base Station Setup | Robot Setup | Tablet Setup | OutdoorNav URL via Local WiFi | OutdoorNav URL via Internet/Cellular |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ----------------------------------------- |
| Base Station | Base Station with WiFi for near-range operations; optional LTE also available on robot for long-range operations | Pre-configured at factory | Pre-configured at factory; see also [Enabling LTE (Cellular) Networking on Robot](#lte-setup) for optional setup | Pre-configured at factory | http://192.168.132.1:8080 | See [Remote Access Setup](#remote-access) |
-| Customer WiFi Network | Customer WiFi for near-range operations; optional LTE also available on robot for long-range operations | N/A | See [Updating the WiFi SSID or Password on Robot](#robot-wifi-setup); see also [Enabling LTE (Cellular) Networking on Robot](#lte-setup) for optional setup | See [Windows 10 instructions](https://support.microsoft.com/en-us/windows/connect-to-a-wi-fi-network-in-windows-1f881677-b569-0cd5-010d-e3cd3579d263) for connecting to Customer WiFi network | http://:8080 | See [Remote Access Setup](#remote-access) |
+| Customer WiFi Network | Customer WiFi for near-range operations; optional LTE also available on robot for long-range operations | N/A | See [Updating the WiFi SSID or Password on Robot](#robot-wifi-setup); see also [Enabling LTE (Cellular) Networking on Robot](#lte-setup) for optional setup | See [Windows 10 instructions](https://support.microsoft.com/en-us/windows/connect-to-a-wi-fi-network-in-windows-1f881677-b569-0cd5-010d-e3cd3579d263) for connecting to Customer WiFi network | http://\:8080 | See [Remote Access Setup](#remote-access) |
| Cellular Only | Uses cellular in robot + separate cellular in Tablet | N/A | See [Enabling LTE (Cellular) Networking on Robot](#lte-setup) for setup | Pre-configured at factory or use USB-tethering to a cell phone | N/A | See [Remote Access Setup](#remote-access) |
@@ -914,10 +914,7 @@ modes for deploying Husky Observer, which are outlined below.
/>
Cellular Only Mode
- (
+ (
Some icons created by Freepik - Flaticon
)
@@ -1074,7 +1071,7 @@ OutdoorNav UI manually after the switchover.
:::note
-Refer to the [OutdoorNav User Manual](/docs_outdoornav_user_manual/web_user_interface/ui_overview#general-settings)
+Refer to the [OutdoorNav User Manual](/docs_outdoornav_user_manual/web_user_interface/ui_overview#config-general-settings)
for details on switching between WiFi and cellular modes.
:::
@@ -1104,7 +1101,7 @@ of configuration is required to use them.
See [Wired Network Connection](#wired-network-connection) for details.
1. Connect an Ethernet cable from the configured port on your laptop to the
debug/expansion port on the top of the robot.
-1. SSH to the robot: `ssh administrator@192.168.131.1`. (See [Appendix A](#network-setup) for credentials.)
+1. SSH to the robot: `ssh administrator@192.168.131.1`. (See [Appendix A](#networking-configuration) for credentials.)
1. Ensure that the robot has internet access (eg. `ping 8.8.8.8`).
1. Register your ngrok auth token (shown [here](https://dashboard.ngrok.com/get-started/setup)) with the ngrok agent:
e.g., `ngrok config add-authtoken (your_auth_token)`
@@ -1212,7 +1209,7 @@ Husky Observer has been validated with the [SwiftNav Skylark](https://www.swiftn
service. Follow the steps below to set up the Skylark service.
1. [Sign up for a Skylark account](https://account.swiftnav.com/sign-up) if you do not have one. (Note that Clearpath does not provide a Skylark account.)
-1. Create a Skylark subscription (https://{your_account_name}.account.swiftnav.com/subscriptions) from the subscriptions tab.
+1. Create a Skylark subscription (https://\{your_account_name\}.account.swiftnav.com/subscriptions) from the subscriptions tab.
1. Create a new Device in the "Devices" tab corresponding to the robot that will be receiving the corrections.
1. Configure the "position" SwiftNav Duro to communicate with the Skylark service.
1. Ensure that the [Swift Console](https://support.swiftnav.com/support/solutions/articles/44001903699-installing-swift-console)
@@ -1331,7 +1328,7 @@ during the execution of the mission.
#### Autonomous Missions {#autonomous-missions}
Refer to the OutdoorNav User Manual for details on the
-[Autonomous Mode](/docs_outdoornav_user_manual/web_user_interface/ui_overview#autonomous-features),
+[Autonomous Mode](/docs_outdoornav_user_manual/web_user_interface/ui_overview#autonomy-features),
including details on [Autonomous Docking](/docs_outdoornav_user_manual/web_user_interface/ui_overview#autonomous-docking).
#### Retrieving Results from Autonomous Missions
diff --git a/docs_versioned_docs/version-ros1noetic/ros/networking/networking.mdx b/docs_versioned_docs/version-ros1noetic/ros/networking/networking.mdx
index 65bc795ad..469e5bb26 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/networking/networking.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/networking/networking.mdx
@@ -13,7 +13,7 @@ robot, refer to the robot-specific tutorials, such as the
:::note
-Contact our Support team at if you have any questions.
+Contact our Support team at \ if you have any questions.
:::
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/advanced/nodelet_everything.md b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/advanced/nodelet_everything.md
index 2f3e1bc36..46e5d3197 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/advanced/nodelet_everything.md
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/advanced/nodelet_everything.md
@@ -56,8 +56,8 @@ between Nodes and Nodelets, which is why we use a dynamic wrapping Node
below.
You don't actually NEED the wrapping node - you can run the nodelet
-with [nodelet standalone pkg/nodelet]{.title-ref}. However this
-precludes using [rosrun pkg node]{.title-ref}, which is very
+with [nodelet standalone pkg/nodelet]\{.title-ref\}. However this
+precludes using [rosrun pkg node]\{.title-ref\}, which is very
user-friendly.
Now that I've convinced you, please read the rest of the nodelet docs:
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/getting_started_with_ubuntu.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/getting_started_with_ubuntu.mdx
index e51c856bd..4086de31a 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/getting_started_with_ubuntu.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/getting_started_with_ubuntu.mdx
@@ -19,15 +19,15 @@ To use the terminal, simply type in a command in the window and push
located in is called the "working directory" and shown at the start of
the terminal line. Here are some of the most used commands:
-| Command | Description |
-| --------------------- | ---------------------------------------------------------------- |
-| ls | Lists files and folders |
-| cd | Change the working directory to |
-| pwd | Prints the current working directory |
-| cp | Copies to |
-| sudo | Executes the command as the root user |
-| mkdir | Creates a directory in your working directory named |
-| gedit or nano | Opens a text editor to edit |
+| Command | Description |
+| ---------------------- | ----------------------------------------------------------------- |
+| ls | Lists files and folders |
+| cd \ | Change the working directory to \ |
+| pwd | Prints the current working directory |
+| cp \ \ | Copies \ to \ |
+| sudo | Executes the command as the root user |
+| mkdir \ | Creates a directory in your working directory named \ |
+| gedit or nano \ | Opens a text editor to edit \ |
Ubuntu programs are installed from repositories. This allows for very
easy installation of programs and applications through the apt system.
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/practical_example.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/practical_example.mdx
index d066b83d8..ee441ee8f 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/practical_example.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/beginner/practical_example.mdx
@@ -21,7 +21,7 @@ things....
2. Get VMWare Player, and use the virtual disk above. If you don't want
to use the provided image, follow the tutorial here (after
installing Ubuntu 20.04):
-
+ http://wiki.ros.org/noetic/Installation/Ubuntu
Throughout the rest of the tutorials, we will be referencing the ROS
cheatsheet available [here](http://bit.ly/1RCVMaB).
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_publisher.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_publisher.mdx
index 9fb751853..d8a1ff805 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_publisher.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_publisher.mdx
@@ -122,8 +122,8 @@ Lets break down this code line by line,
```
These lines includes the headers that we are going to need. The
-**** header is required for ROS functionality and the
-**** is added so that we can create a message
+**\** header is required for ROS functionality and the
+**\** is added so that we can create a message
of that type.
```c
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_subscriber.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_subscriber.mdx
index 23829c4b1..326ef3069 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_subscriber.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/creating_subscriber.mdx
@@ -73,9 +73,9 @@ from nav_msgs.msg import Odometry
Much like the C++ publisher code, this includes the rospy library and
imports the Odometry message type from **nav_msgs.msg**. To learn more
-about a specific message type, you can visit to
+about a specific message type, you can visit http://docs.ros.org to
see it's definition, for example, we are using
- . The next
+http://docs.ros.org/api/nav_msgs/html/msg/Odometry.html . The next
block of code imports the pygame libraries and sets up the initial
conditions for our display.
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/launch_files.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/launch_files.mdx
index f99b6c6da..ddd9815c4 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/launch_files.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/launch_files.mdx
@@ -40,7 +40,7 @@ contained between a pair of launch tags
```
-To actually start a node, the tags are used, the pkg, type and
+To actually start a node, the \ tags are used, the pkg, type and
name argument are required.
```
@@ -107,16 +107,16 @@ on-board PC on startup to get things going.
```
-The first thing to notice is the tags which are required for
+The first thing to notice is the \ tags which are required for
all launch files. The next line finds what port Husky is connected to,
and saves it to an argument named "port". The node "kinematic_node"
from the package"clearpath_base" is then started in the "husky" name
space.
-Parameters within the tags are private to that namepace. The
+Parameters within the \ tags are private to that namepace. The
"port" argument that was defined earlier is set to the port parameter.
Several other parameters are populated using the YAML format with
- tags.
+\ tags.
Along with the kinematic_node node, this launch file also starts
husky_base_diagnositcs and husky_base_odom. You can see that the
diff --git a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/udev_rules.mdx b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/udev_rules.mdx
index dfa093119..cfa0fabda 100644
--- a/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/udev_rules.mdx
+++ b/docs_versioned_docs/version-ros1noetic/ros/ros/tutorials/ros101/intermediate/udev_rules.mdx
@@ -58,7 +58,7 @@ a /dev/hokuyo symlink to an IMU. There are many potential matching tags,
and the best way to pick the useful ones is to get all the device
attributes straight from udev.
-Run the following command, inserting a **** such as
+Run the following command, inserting a **\** such as
**/dev/ttyACM0**:
```
@@ -66,7 +66,7 @@ udevadm info -a -p $(udevadm info -q path -n )
```
You will get a list of all device attributes visible to udev. looking at
-device [/dev/ttyACM0]{.title-ref}
+device [/dev/ttyACM0]\{.title-ref\}
```bash
KERNEL=="ttyACM0"
@@ -97,7 +97,7 @@ SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="0483", ATTRS{idProdu
Due to the way udev is designed, you can only pull in the tags from one
parent device. So in the above example you can always use the KERNEL and
theSUBSYSTEM tag in your udev rule, but you cannot use both DRIVERS
-andATTRS{idVendor} to do matching. Usually this is not a problem, since
+and ATTRS\{idVendor\} to do matching. Usually this is not a problem, since
idVendor and idProduct are always present, and identify the majority of
device types uniquely.
@@ -197,7 +197,7 @@ udevadm test $(udevadm info -q path -n /dev/ttyACM0)
## Things to keep in mind
- Check that your rule follows the naming convention --
- -.rules. Technically you can have
+ \-\.rules. Technically you can have
multiple rules for the same device, and the number determines what
order they'd get executed in. Since we're writing addon rules, a
priority of 99 is safest.
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/add-ons.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/add-ons.mdx
index 9e992ffdc..946cf0251 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/add-ons.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/add-ons.mdx
@@ -31,5 +31,5 @@ Thses pages will list subsystems like:
We suggest you:
1. Review our documentation of these accessories.
-2. If you want Clearpath Robotics to integrate accessories on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-3. Contact our Support team at if you have any questions.
+2. If you want Clearpath Robotics to integrate accessories on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+3. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/din_rail.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/din_rail.mdx
index 748b70ff0..235b8e2fc 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/din_rail.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/din_rail.mdx
@@ -22,46 +22,49 @@ sidebar_position: 4
## DIN Rail Lengths
-Click to expand
+
## Common Parts
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/computers/mini_itx.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/computers/mini_itx.mdx
index 78c5e7d9b..31169e695 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/computers/mini_itx.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/computers/mini_itx.mdx
@@ -16,14 +16,14 @@ To install and configure software on your Mini ITX computer, see
:::note
If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team
-at , whether you want to use a new Clearpath Robotics platform,
+at \, whether you want to use a new Clearpath Robotics platform,
or reuse your existing vehicle.
:::
:::note
-Contact our Support team at if you have any questions.
+Contact our Support team at \ if you have any questions.
:::
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/manipulators/manipulators.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/manipulators/manipulators.mdx
index 8171ee632..62e08fcf2 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/manipulators/manipulators.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/manipulators/manipulators.mdx
@@ -28,5 +28,5 @@ We suggest you:
1. Review our documentation of the manipulators related to your robot integration.
2. Review the related Further Reading section.
3. If you are planning to purchase a manipulator, consider visiting our [Component Store](https://store.clearpathrobotics.com/).
-4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-5. Contact our Support team at if you have any questions.
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
index acc039409..7997cd723 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
@@ -52,7 +52,7 @@ The number of rows and columns is dependent on the robot platform.
Refer to the integration pages for our robots for more details:
- [Dingo](../indoor_robots/dingo/integration_dingo/integration_dingo.mdx)
-- [Husky](../outdoor_robots/husky/integration_husky/integration_husky.mdx)
+- [Husky A200](../outdoor_robots/husky/integration_husky)
- [Jackal](../outdoor_robots/jackal/integration_jackal.mdx)
- [Warthog](../outdoor_robots/warthog/integration_warthog/integration_warthog.mdx)
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/sensors.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/sensors.mdx
index b5670730d..ec123e019 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/sensors.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/sensors.mdx
@@ -28,5 +28,5 @@ We suggest you:
1. Review our documentation of the sensors related to your robot integration.
2. Review the related _Further Reading_ section.
3. If you are planning to purchase a sensor for standalone use, or for integration with a non-Clearpath system, consider visiting our Component Store, [store.clearpathrobotics.com](https://store.clearpathrobotics.com/).
-4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at , whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
-5. Contact our Support team at if you have any questions.
+4. If you want Clearpath Robotics to integrate sensors on your robot, contact our Sales team at \, whether you want to use a new Clearpath Robotics platform, or reuse your existing vehicle.
+5. Contact our Support team at \ if you have any questions.
diff --git a/docs_versioned_docs/version-ros2humble/robots/common/physical_tools.mdx b/docs_versioned_docs/version-ros2humble/robots/common/physical_tools.mdx
index 11af92caf..84f14e462 100644
--- a/docs_versioned_docs/version-ros2humble/robots/common/physical_tools.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/common/physical_tools.mdx
@@ -9,7 +9,7 @@ The intention of this page is to show you what tools we use for maintenance, and
:::info Contact Us
-Contact our Sales team at if you want us to add sensors or custom attachments to your robot.
+Contact our Sales team at \ if you want us to add sensors or custom attachments to your robot.
We can suggest hardware and software that will meet your application goals.
You can see some of our past Integration Services projects [here](https://clearpathrobotics.com/integration-services/).
diff --git a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/maintenance_boxer.mdx b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/maintenance_boxer.mdx
index 32e278a16..89350362c 100644
--- a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/maintenance_boxer.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/maintenance_boxer.mdx
@@ -52,8 +52,8 @@ If you see any errors, contact [Support](#support).
### Starting From Scratch
-If Boxer's computer has become inoperable, or for any reason you want to restore it to the factory state, you can
-reinstall the operating system by following the steps outlined [Boxer Backpack Computer Software Setup](tutorials_boxer.mdx#boxer-software-setup).
+If Boxer's computer has become inoperable, or for any reason you want to restore it to the factory state,
+contact [Support](#support).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/user_manual_boxer.mdx b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/user_manual_boxer.mdx
index 9cba0c66f..79f30387b 100644
--- a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/user_manual_boxer.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/boxer/user_manual_boxer.mdx
@@ -230,7 +230,7 @@ Connect the Boxer to the Wi-Fi network using the steps below.
Refer to [Connecting to a robot using an Ethernet cable](https://docs.ottomotors.com/en/30495-30527-connecting-to-a-robot-using-ethernet.html) and
[Connecting a robot to a network](https://docs.ottomotors.com/en/30495-30526-connecting-a-robot-to-a-network.html) for more details.
-1. Configure a network port on your laptop with the IP address <10.255.255.200>.
+1. Configure a network port on your laptop with the IP address \<10.255.255.200\>.
2. Connect a network cable from the port on your laptop to the network port on the rear of the Base Unit.
-3. On your laptop, open a web-browser like Google Chrome, and go to the address
+3. On your laptop, open a web-browser like Google Chrome, and go to the address http://10.255.255.1:8090
4. Enter the required information to connect to your network.
See your IT administrator for proper settings for your network.
@@ -285,7 +285,7 @@ The Backpack Computer is an add-on computer that is networked with the Base Unit
This Backpack Computer can be used to integrate peripherals, like sensors and manipulators.
A ROS bridge automatically runs upon booting the Backpack Computer, and transmits the Base Unit computer's ROS data to the Backpack Computer.
This ROS bridge allows you to leverage the Base Unit for your own application.
-The Backpack Computer uses Netplan as its network configuration tool, and has a static IP address of <192.168.131.1>.
+The Backpack Computer uses Netplan as its network configuration tool, and has a static IP address of \<192.168.131.1\>.
#### Connecting to the Backpack Computer
@@ -293,7 +293,7 @@ You can connect to the Backpack Computer on Boxer over a wired or Wi-Fi connecti
To connect to the Backpack Computer over a wired connection:
-1. Configure a network port on your laptop with the IP address <192.168.131.100>.
+1. Configure a network port on your laptop with the IP address \<192.168.131.100\>.
2. Connect a network cable from your laptop to an open network port on the Backpack Computer.
3. Test the connection between the user computer and Backpack Computer by opening a terminal and entering: `ping 192.168.131.1 `
4. From your laptop's terminal, you can access the Backpack Computer by entering: `ssh administrator@192.168.131.1`
@@ -393,7 +393,7 @@ This section details how to get the Robot driving around using the OTTO user int
3. Using the base Boxer's hostname or static IP, open the OTTO App by entering the following in your laptop's web-browser:
- http://:5000
+ http://\:5000
4. You are now ready to start driving your system.
@@ -432,7 +432,7 @@ Detailed instructions for mapping can be found here:
To use your controller, it must be paired with your Boxer and powered on.
If your purchased the Backpack Computer from Clearpath Robotics, your controller is already paired with your Boxer.
If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the
-[Boxer Tutorials](tutorials_boxer.mdx#pairing-the-controller).
+[Boxer Tutorials](tutorials_boxer.mdx).
To use the controller:
diff --git a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/dingo/user_manual_dingo.mdx b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/dingo/user_manual_dingo.mdx
index a045145e9..518384a33 100644
--- a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/dingo/user_manual_dingo.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/dingo/user_manual_dingo.mdx
@@ -485,7 +485,7 @@ See the [Dingo Tutorials](tutorials_dingo.mdx) for details.
To use your controller, it must be paired with your Dingo and powered on.
If your purchased the Onboard Computer from Clearpath Robotics, your controller is already paired with your Dingo.
-If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the [Dingo Tutorials](tutorials_dingo.mdx#pairing-the-controller).
+If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the [Dingo Tutorials](tutorials_dingo.mdx).
To teleoperate Dingo, first clear the motion-stop.
Then, power on the controller by pressing the `PS` button on the controller.
@@ -517,30 +517,30 @@ If you are not seeing any action, refer to [Support](#dingo-support) to get in t
value="D100"
label="Dingo 1.0"
>
-For Dingo 1.0, when finished with the Dingo, press and release the power button to power it off.
-Then remove the batteries for charging.
+ For Dingo 1.0, when finished with the Dingo, press and release the power button to power it off.
+ Then remove the batteries for charging.
-Dingo's batteries are charged outside the Dingo using the charger(s) provided.
+ Dingo's batteries are charged outside the Dingo using the charger(s) provided.
-Alternatively, if you have multiple batteries, you can hot-swap them one at a time.
-The system will remain operational while hot-swapping as long as there is at least one battery in the system or the system is connected to shore power prior to removing the batteries.
-Note that plugging in shore power will engage a motion-stop and it is not possible to drive Dingo while connected to shore power.
-
-The Sealed Lead-Acid batteries have overcurrent protection in the form of an ATO fuse.
-The lithium batteries include integrated protections against fault due to overcurrent, overdischarge, and short circuit.
-The batteries are rugged and designed for the demanding environments into which Dingo may be deployed.
+ Alternatively, if you have multiple batteries, you can hot-swap them one at a time.
+ The system will remain operational while hot-swapping as long as there is at least one battery in the system or the system is connected to shore power prior to removing the batteries.
+ Note that plugging in shore power will engage a motion-stop and it is not possible to drive Dingo while connected to shore power.
+ The Sealed Lead-Acid batteries have overcurrent protection in the form of an ATO fuse.
+ The lithium batteries include integrated protections against fault due to overcurrent, overdischarge, and short circuit.
+ The batteries are rugged and designed for the demanding environments into which Dingo may be deployed.
-For Dingo 1.5, to charge the batteries, simply connect the manual charger to the charge port on the front of the Dingo. Charging can take place while the unit is powered,
-or unpowered, or while the unit is connected to DC Shore Power. The charging current for the SLA system is 6A, and 7A for the LiFEPO4 system. Care must be
-taken when charging while the system is powered, as if the load/total current is higher than the supplied charge current the batteries will continue to drain.
-If the total system current is less than the charge current the batteries will charge, but at a reduced rate as the system will be using a portion of the
-charger current to maintain operation.
+ For Dingo 1.5, to charge the batteries, simply connect the manual charger to the charge port on the front of the Dingo. Charging can take place while the unit is powered,
+ or unpowered, or while the unit is connected to DC Shore Power. The charging current for the SLA system is 6A, and 7A for the LiFEPO4 system. Care must be
+ taken when charging while the system is powered, as if the load/total current is higher than the supplied charge current the batteries will continue to drain.
+ If the total system current is less than the charge current the batteries will charge, but at a reduced rate as the system will be using a portion of the
+ charger current to maintain operation.
+
For multi-battery systems the charge current is distributed across the number of batteries present in the system, so charging time will increase appropriately.
diff --git a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx
index f16d32df3..379451bff 100644
--- a/docs_versioned_docs/version-ros2humble/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/indoor_robots/ridgeback/user_manual_ridgeback.mdx
@@ -192,7 +192,7 @@ on completing the networking setup.
To use your controller, it must be paired with your Ridgeback and powered on.
For a standard Ridgeback with the Onboard Computer from Clearpath Robotics, the controller is already paired with your Ridgeback.
If your controller has become unpaired or if you wish to pair a new controller, following the instructions in the
-[Ridgeback Tutorials](tutorials_ridgeback.mdx#pairing-the-controller).
+[Ridgeback Tutorials](tutorials_ridgeback.mdx).
To teleoperate Ridgeback, first clear the motion-stop.
Then, power on the controller by pressing the `PS` button on the controller.
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/_category_.json b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/_category_.json
index 6d02f295b..79472b97e 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/_category_.json
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/_category_.json
@@ -1,4 +1,4 @@
{
- "label": "Husky",
- "position": 2
+ "label": "Husky A200",
+ "position": 1
}
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
index 7edc17501..f15fc20a4 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
@@ -1,13 +1,11 @@
---
-title: Husky Integration
+title: Husky A200 Integration
sidebar_position: 1
toc_min_heading_level: 2
toc_max_heading_level: 4
---
import ComponentIntroductionHusky from "/components/introduction_husky.mdx";
-import ComponentPacsFasteners from "/components/pacs_fasteners.mdx";
-import ComponentPacsMechanical from "/components/pacs_mechanical.mdx";
import ComponentCommonSoftwareIntegration from "/components/common_software_integration.mdx";
import ComponentTableHuskyOne from "/components/table_husky_1.mdx";
import Support from "/components/support.mdx";
@@ -45,7 +43,16 @@ Misumi also offers a range of configurable products for this 20 X 20 extrusion t
### Mechanical, PACS™
-
+[PACS™](../../../accessories/pacs) is a Clearpath Robotics standard.
+We add a grid of M5×0.8 holes onto the top plate of the robot.
+This grid of holes has a 80 mm X 80 mm spacing.
+You can create your own brackets to interface with these holes, or can use an existing Clearpath Robotics designed bracket.
+
+:::note
+
+Our [Sensors](../../../accessories/sensors) and [Accessories](../../../accessories/add-ons) pages indicate the required bracket for the particular attachment.
+
+:::
Refer to the following pages for Husky brackets that can simplify your integration.
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/maintenance_husky.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/maintenance_husky.mdx
index 94af8abf0..d5508a466 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/maintenance_husky.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/maintenance_husky.mdx
@@ -1,5 +1,5 @@
---
-title: Husky Maintenance
+title: Husky A200 Maintenance
sidebar_label: Maintenance
sidebar_position: 5
---
@@ -200,41 +200,42 @@ The [Common Replacement Items](#husky_maintenance_common_replacement_items) sect
:::
-Click to expand
-
-
-
-
- Husky's rear battery access
-
-
-
-
-
-
-
-
- User power fuses
-
-
-
-
-
-
-
-
- Main battery fuse
-
-
+
+ Click to expand
+
+
+
+
+ Husky's rear battery access
+
+
+
+
+
+
+
+
+ User power fuses
+
+
+
+
+
+
+
+
+ Main battery fuse
+
+
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/troubleshooting_husky.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/troubleshooting_husky.mdx
index acc22d292..6178e9fe1 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/troubleshooting_husky.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/troubleshooting_husky.mdx
@@ -1,5 +1,6 @@
---
-title: Troubleshooting
+title: Husky A200 Troubleshooting
+sidebar_label: Troubleshooting
sidebar_position: 6
---
@@ -136,7 +137,7 @@ There is no way to change this behaviour on your Husky.
It's possible the robot has reached the thermal limit, or current limit.
The maximum current limits are set to 26 A, however, as the motors are only rated for 10.7 A continuous, anything above that will trigger the current limit eventually, the higher above this limit, the more quickly it will trigger.
-If you are unsure whether this is the case, feel free to contact with a rosbag of your system.
+If you are unsure whether this is the case, feel free to contact \ with a rosbag of your system.
:::note
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/tutorials_husky.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/tutorials_husky.mdx
index 8895be4f5..13816f29a 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/tutorials_husky.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/tutorials_husky.mdx
@@ -1,5 +1,5 @@
---
-title: Husky Tutorials
+title: Husky A200 Tutorials
sidebar_label: Tutorials
sidebar_position: 4
toc_min_heading_level: 2
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/user_manual_husky.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/user_manual_husky.mdx
index 113815dc3..c365cbab4 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/user_manual_husky.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/husky/user_manual_husky.mdx
@@ -1,5 +1,5 @@
---
-title: Husky User Manual
+title: Husky A200 User Manual
sidebar_label: User Manual
sidebar_position: 1
toc_min_heading_level: 2
@@ -129,7 +129,7 @@ $$
$$
$v$ represents the instantaneous translational speed of the platform and $\omega$ the instantaneous rotational speed.
-$v_{r}$ and $v_{l}$ are the right and left wheel velocities, respectively.
+$v_\{r\}$ and $v_\{l\}$ are the right and left wheel velocities, respectively.
$W$ is the effective track of the robot, 0.555 m.
### System Specifications
@@ -266,7 +266,10 @@ To teleoperate Husky, first release the motion stop. Then, referring to the foll
### Using ROS
-
+Robot Operating System (ROS) is an extensible framework for controlling and working with robotic systems.
+Clearpath Robotics recommends using ROS with your robot. If this is your first time using ROS, it is strongly
+recommended to run through our series of [ROS tutorials](../../../ros) to learn
+the basics of ROS.
### Battery Charging
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
index beadab449..8aacdf691 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_rails_warthog.mdx
@@ -25,7 +25,7 @@ You can attach your own custom brakets to the extrusions using M5×0.8 T-slot nu
Misumi also offers a range of configurable products that can help with your integration.
-Please email if you want Clearpath's team to design a bracket structure for your application.
+Please email \ if you want Clearpath's team to design a bracket structure for your application.
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/robots.mdx b/docs_versioned_docs/version-ros2humble/robots/robots.mdx
index c488e6eb5..8eec92162 100644
--- a/docs_versioned_docs/version-ros2humble/robots/robots.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/robots.mdx
@@ -29,7 +29,7 @@ The extensibility of ROS has also allowed Clearpath to use it to develop the pro
1. Review the documentation for our robot platforms, sensors, add-ons, and autonomy software.
2. Try some of our tutorials. Some of these tutorials use a simulated robot, so you can try developing with ROS before purchasing hardware.
3. Review some of our [GitHub](https://github.com/clearpathrobotics) repositories.
-4. Discuss your application with our Sales team at , whether you already have a robot or not.
+4. Discuss your application with our Sales team at \, whether you already have a robot or not.
:::
diff --git a/docs_versioned_docs/version-ros2humble/ros/api/lighting.mdx b/docs_versioned_docs/version-ros2humble/ros/api/lighting.mdx
index 397aa1d5c..bbf6a5b59 100644
--- a/docs_versioned_docs/version-ros2humble/ros/api/lighting.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/api/lighting.mdx
@@ -30,7 +30,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -44,7 +44,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -58,7 +58,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -72,7 +72,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -86,7 +86,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -100,7 +100,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -114,7 +114,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -128,7 +128,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -142,7 +142,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -156,7 +156,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -170,7 +170,7 @@ The lighting node will publish the current lighting command directly to the MCU.
@@ -184,7 +184,7 @@ The lighting node will publish the current lighting command directly to the MCU.
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx
index f17921b79..7ad3c1076 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx
@@ -37,62 +37,63 @@ Include your custom mesh without creating a URDF of your own. You can either pro
to the mesh file or if it is included in a ROS 2 package, then you can provide both the package name
and relative link to the install location within the package.
-If you prefer to add a URDF instead, then you can link it directly through the [`platform.extras`](platform/extras.mdx#extras) entry.
+If you prefer to add a URDF instead, then you can link it directly through the [`platform.extras`](platform/extras.mdx) entry.
## Sample
-Sample A200 Links Section
-
-
-
-
-
- Husky A200 with Open User Bay
-
-
-
-In this sample, we will use links to add thin **box** to cover up the user bay.
-
-We add an entry under the **box** list:
-
-```yaml
-box:
- - name: user_bay_cover
- parent: top_plate_link # add it to the top_plate_link
- xyz: [0.0, 0.0, 0.00735] # move it up 6.35mm (thickness of top plate) and move it up 1mm (half height of the box)
- rpy: [0.0, 0.0, 0.0]
- size: [0.4, 0.4, 0.002] # length 400mm, width 400mm and 2mm thick.
-```
-
-
-
-
- Husky A200 with Covered User Bay
-
-
-
-We leave the rest of the lists all empty, for the resulting links section:
-
-```yaml
-links:
+
+ Sample A200 Links Section
+
+
+
+
+
+ Husky A200 with Open User Bay
+
+
+
+ In this sample, we will use links to add thin **box** to cover up the user bay.
+
+ We add an entry under the **box** list:
+
+ ```yaml
box:
- name: user_bay_cover
- parent: top_plate_link
- xyz: [0.0, 0.0, 0.00735]
+ parent: top_plate_link # add it to the top_plate_link
+ xyz: [0.0, 0.0, 0.00735] # move it up 6.35mm (thickness of top plate) and move it up 1mm (half height of the box)
rpy: [0.0, 0.0, 0.0]
- size: [0.4, 0.4, 0.002]
- cylinder: []
- frame: []
- mesh: []
- sphere: []
-```
-
-
+ size: [0.4, 0.4, 0.002] # length 400mm, width 400mm and 2mm thick.
+ ```
+
+
+
+
+ Husky A200 with Covered User Bay
+
+
+
+ We leave the rest of the lists all empty, for the resulting links section:
+
+ ```yaml
+ links:
+ box:
+ - name: user_bay_cover
+ parent: top_plate_link
+ xyz: [0.0, 0.0, 0.00735]
+ rpy: [0.0, 0.0, 0.0]
+ size: [0.4, 0.4, 0.002]
+ cylinder: []
+ frame: []
+ mesh: []
+ sphere: []
+ ```
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx
index d3789177e..3eb7fc666 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx
@@ -98,84 +98,85 @@ We can also lift the **disk** by using a **post**.
## Sample
-Sample A200 Mounts Section
-
-
-
-
-
- Husky A200 with Covered User Bay
-
-
-
-In this sample, we will add a **bracket** to mount a LiDAR to the front of the **Husky A200**.
-
-We select the **_top_plate_mount_d1_**, in other words, the middle (**d**), front (**1**), 80 mm X 80 mm mounting location on the **PACS** top plate.
-
-```yaml
-bracket:
- - parent: top_plate_mount_d1
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- model: horizontal
-```
-
-
-
-
- Husky A200 with D1 Bracket
-
-
-
-Then, we want to add a camera to the sensor arch. However, we will complicate things by adding it upside down to the extrusion.
-
-We choose a **fath_pivot** mount, and then we set its **parent** to the **_sensor_arch_mount_**.
-
-Using the **xyz** entry, we lower the mount by 21 mm to get it under the sensor arch; then, we roll it by $\pi$ to get it upside down.
-
-```yaml
-fath_pivot:
- - parent: sensor_arch_mount # mount atop the sensor arch
- xyz: [0.0, 0.0, -0.021] # lower pivot mount to below the sensor arch
- rpy: [3.1415, 0.0, 0.0] # roll pivot mount to flip it upside down
- angle: 0.0
-```
-
-
-
-
- Husky A200 with upside down Fath Pivot Mount
-
-
-
-Since we did not need a riser, we leave that section empty; the resulting **mounts** section:
-
-```yaml
-mounts:
+
+ Sample A200 Mounts Section
+
+
+
+
+
+ Husky A200 with Covered User Bay
+
+
+
+ In this sample, we will add a **bracket** to mount a LiDAR to the front of the **Husky A200**.
+
+ We select the **_top_plate_mount_d1_**, in other words, the middle (**d**), front (**1**), 80 mm X 80 mm mounting location on the **PACS** top plate.
+
+ ```yaml
bracket:
- parent: top_plate_mount_d1
xyz: [0.0, 0.0, 0.0]
rpy: [0.0, 0.0, 0.0]
model: horizontal
+ ```
+
+
+
+
+ Husky A200 with D1 Bracket
+
+
+
+ Then, we want to add a camera to the sensor arch. However, we will complicate things by adding it upside down to the extrusion.
+
+ We choose a **fath_pivot** mount, and then we set its **parent** to the **_sensor_arch_mount_**.
+
+ Using the **xyz** entry, we lower the mount by 21 mm to get it under the sensor arch; then, we roll it by $\pi$ to get it upside down.
+
+ ```yaml
fath_pivot:
- - parent: sensor_arch_mount
- xyz: [0.0, 0.0, -0.021]
- rpy: [3.1415, 0.0, 0.0]
+ - parent: sensor_arch_mount # mount atop the sensor arch
+ xyz: [0.0, 0.0, -0.021] # lower pivot mount to below the sensor arch
+ rpy: [3.1415, 0.0, 0.0] # roll pivot mount to flip it upside down
angle: 0.0
- riser: []
- sick: []
- post: []
- disk: []
-```
-
-
+ ```
+
+
+
+
+ Husky A200 with upside down Fath Pivot Mount
+
+
+
+ Since we did not need a riser, we leave that section empty; the resulting **mounts** section:
+
+ ```yaml
+ mounts:
+ bracket:
+ - parent: top_plate_mount_d1
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ model: horizontal
+ fath_pivot:
+ - parent: sensor_arch_mount
+ xyz: [0.0, 0.0, -0.021]
+ rpy: [3.1415, 0.0, 0.0]
+ angle: 0.0
+ riser: []
+ sick: []
+ post: []
+ disk: []
+ ```
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx
index d6cdf0f56..33a36d801 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx
@@ -49,139 +49,140 @@ You can also skip to each section to get an explanation of each part of the samp
5. [**Mounts Sample**](./mounts.mdx#sample)
6. [**Sensors Sample**](./sensors/overview.mdx#sample)
-Sample A200 YAML
-
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform/overview.mdx
index 27bf7097c..aa116e901 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform/overview.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform/overview.mdx
@@ -19,95 +19,45 @@ The platform section is divided into the following sections:
## Sample
-Sample A200 Platform Section
-
+
+ Sample A200 Platform Section
+
-
-
-
- Husky A200 with Default Top Plate
-
-
+
+
+
+ Husky A200 with Default Top Plate
+
+
-In this sample, we swapped the top plate from the **_default_** model to the **_pacs_** model. Notice all the links added by the **_pacs_** plate below, compared to the **_default_** plate above.
+ In this sample, we swapped the top plate from the **_default_** model to the **_pacs_** model. Notice all the links added by the **_pacs_** plate below, compared to the **_default_** plate above.
-```yaml
- - name: top_plate
- type: a200.top_plate
- model: pacs # switched from 'default' to 'pacs'
- parent: default_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- enabled: true
-```
-
-
-
-
- Husky A200 with PACS Top Plate
-
-
-
-Then, we added a sensor arch to add our sample sensors to. We can do this by adding the **attachment**, **sensor_arch** and setting the model to **_sensor_arch_300_**.
-
-```yaml
- - name: sensor_arch
- type: a200.sensor_arch
- model: sensor_arch_300
- parent: default_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- enabled: true
-```
-
-
-
-
- Husky A200 with 300mm Sensor Arch
-
-
-
-In terms of the **front_bumper** and **rear_bumper**, we left these as defaults. And, since we are not including any customization URDF or launch parameters; the resulting **platform** section look like this:
-
-```yaml
-platform:
- battery:
- model: ES20_12C
- configuration: S2P1
- controller: ps4
- attachments:
- - name: front_bumper
- type: a200.bumper
- model: default
- parent: front_bumper_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- enabled: true
- extension: 0.0
- - name: rear_bumper
- type: a200.bumper
- model: default
- parent: rear_bumper_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- enabled: true
- extension: 0.0
+ ```yaml
- name: top_plate
type: a200.top_plate
- model: pacs
+ model: pacs # switched from 'default' to 'pacs'
parent: default_mount
xyz: [0.0, 0.0, 0.0]
rpy: [0.0, 0.0, 0.0]
enabled: true
+ ```
+
+
+
+
+ Husky A200 with PACS Top Plate
+
+
+
+ Then, we added a sensor arch to add our sample sensors to. We can do this by adding the **attachment**, **sensor_arch** and setting the model to **_sensor_arch_300_**.
+
+ ```yaml
- name: sensor_arch
type: a200.sensor_arch
model: sensor_arch_300
@@ -115,10 +65,61 @@ platform:
xyz: [0.0, 0.0, 0.0]
rpy: [0.0, 0.0, 0.0]
enabled: true
- extras:
- urdf: {}
- ros_parameters: {}
-```
+ ```
+
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors/overview.mdx
index 4f439dcd4..ccf1693ca 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors/overview.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors/overview.mdx
@@ -22,135 +22,55 @@ By default, we pass tested parameters that are used on Clearpath robots.
## Sample
-Sample A200 Sensors Section
-
-
-
-
-
- Husky A200 with upside down Fath Pivot Mount
-
-
-
-In this sample, we first add the `velodyne_lidar` to the `sensor_arch_mount` by simply changing the parent link.
-
-```yaml
-lidar3d:
- - model: velodyne_lidar
- urdf_enabled: true
- launch_enabled: true
- parent: sensor_arch_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- ros_parameters:
- velodyne_driver_node:
- frame_id: lidar3d_0_laser
- device_ip: 192.168.131.25
- port: 2368
- model: VLP16
- velodyne_transform_node:
- model: VLP16
- fixed_frame: lidar3d_0_laser
- target_frame: lidar3d_0_laser
-```
-
-
-
-
- Husky A200 with LiDAR 3D on Sensor Arch
-
-
-
-Next, we will add a `hokuyo_ust` to the **bracket** we added earlier. Since that is the first **bracket**, then it's mounting location will be: `bracket_0_mount`; setting the parent link of the sensor, we get:
-
-```yaml
-lidar2d:
- - model: hokuyo_ust
- urdf_enabled: true
- launch_enabled: true
- parent: bracket_0_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- ros_parameters:
- urg_node:
- laser_frame_id: lidar2d_0_laser
- ip_address: 192.168.131.20
- ip_port: 10940
- angle_min: -2.356
- angle_max: 2.356
-```
-
-
-
-
- Husky A200 with LiDAR 2D on D1 Bracket
-
-
-
-For the final step, we will add an `intel_realsense` to the **fath_pivot** mount that we added. Because it is the first **fath_pivot**, it's mounting location will be: `fath_pivot_0_mount`; setting the parent link of the sensor:
-
-```yaml
-camera:
- - model: intel_realsense
- urdf_enabled: true
- launch_enabled: true
- parent: fath_pivot_0_mount
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- ros_parameters:
- intel_realsense:
- camera_name: camera_0
- device_type: d435
- serial_no: '0'
- enable_color: true
- rgb_camera.profile: 640,480,30
- enable_depth: true
- depth_module.profile: 640,480,30
- pointcloud.enable: true
-```
-
-
-
-
- Husky A200 with Intel RealSense
-
-
-
-Leaving the other sections empty, leaves us with the full sensors section:
-
-```yaml
-sensors:
- camera:
- - model: intel_realsense
+
+ Sample A200 Sensors Section
+
+
+
+
+
+ Husky A200 with upside down Fath Pivot Mount
+
+
+
+ Next, we will add a `hokuyo_ust` to the **bracket** we added earlier. Since that is the first **bracket**, then it's mounting location will be: `bracket_0_mount`; setting the parent link of the sensor, we get:
+
+ ```yaml
lidar2d:
- model: hokuyo_ust
urdf_enabled: true
@@ -165,25 +85,106 @@ sensors:
ip_port: 10940
angle_min: -2.356
angle_max: 2.356
- lidar3d:
- - model: velodyne_lidar
+ ```
+
+
+
+
+ Husky A200 with LiDAR 2D on D1 Bracket
+
+
+
+ For the final step, we will add an `intel_realsense` to the **fath_pivot** mount that we added. Because it is the first **fath_pivot**, it's mounting location will be: `fath_pivot_0_mount`; setting the parent link of the sensor:
+
+ ```yaml
+ camera:
+ - model: intel_realsense
urdf_enabled: true
launch_enabled: true
- parent: sensor_arch_mount
+ parent: fath_pivot_0_mount
xyz: [0.0, 0.0, 0.0]
rpy: [0.0, 0.0, 0.0]
ros_parameters:
- velodyne_driver_node:
- frame_id: lidar3d_0_laser
- device_ip: 192.168.131.25
- port: 2368
- model: VLP16
- velodyne_transform_node:
- model: VLP16
- fixed_frame: lidar3d_0_laser
- target_frame: lidar3d_0_laser
-
-```
-
-
+ intel_realsense:
+ camera_name: camera_0
+ device_type: d435
+ serial_no: '0'
+ enable_color: true
+ rgb_camera.profile: 640,480,30
+ enable_depth: true
+ depth_module.profile: 640,480,30
+ pointcloud.enable: true
+ ```
+
+
+
+
+ Husky A200 with Intel RealSense
+
+
+
+ Leaving the other sections empty, leaves us with the full sensors section:
+
+ ```yaml
+ sensors:
+ camera:
+ - model: intel_realsense
+ urdf_enabled: true
+ launch_enabled: true
+ parent: fath_pivot_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ intel_realsense:
+ camera_name: camera_0
+ device_type: d435
+ serial_no: '0'
+ enable_color: true
+ rgb_camera.profile: 640,480,30
+ enable_depth: true
+ depth_module.profile: 640,480,30
+ pointcloud.enable: true
+ gps: []
+ imu: []
+ lidar2d:
+ - model: hokuyo_ust
+ urdf_enabled: true
+ launch_enabled: true
+ parent: bracket_0_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ urg_node:
+ laser_frame_id: lidar2d_0_laser
+ ip_address: 192.168.131.20
+ ip_port: 10940
+ angle_min: -2.356
+ angle_max: 2.356
+ lidar3d:
+ - model: velodyne_lidar
+ urdf_enabled: true
+ launch_enabled: true
+ parent: sensor_arch_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ ros_parameters:
+ velodyne_driver_node:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.25
+ port: 2368
+ model: VLP16
+ velodyne_transform_node:
+ model: VLP16
+ fixed_frame: lidar3d_0_laser
+ target_frame: lidar3d_0_laser
+
+ ```
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/serial.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/serial.mdx
index 3b2f2a2bf..c378dee62 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/serial.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/serial.mdx
@@ -11,11 +11,11 @@ The Clearpath serial number is composed of two sections, separated by a hyphen,
At this moment, the supported robot platforms are:
-1. [Husky A200](../../../robots/outdoor_robots/husky/user_manual_husky.mdx): `a200-0000`
-2. [Jackal J100](../../../robots/outdoor_robots/jackal/user_manual_jackal.mdx): `j100-0000`
-3. [Warthog W200](../../../robots/outdoor_robots/warthog/user_manual_warthog.mdx): `w200-0000`
+1. [Husky A200](../../../robots/outdoor_robots/husky/user_manual_husky): `a200-0000`
+3. [Jackal J100](../../../robots/outdoor_robots/jackal/user_manual_jackal.mdx): `j100-0000`
+4. [Warthog W200](../../../robots/outdoor_robots/warthog/user_manual_warthog.mdx): `w200-0000`
-Every robot platform has specific [attachments](#attachments) that are selected based on the serial number passed. Therefore, it is **required** that a serial number is specified in the `robot.yaml`.
+Every robot platform has specific attachments that are selected based on the serial number passed. Therefore, it is **required** that a serial number is specified in the `robot.yaml`.
## Sample
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx
index 24f233af8..ce5809099 100644
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx
@@ -12,7 +12,7 @@ Proper networking setup is crucial in setting up the ROS 2 middleware and to ens
The username indicates the username that will be used to run all ROS nodes. If this username needs to be changed then the robot
services must be reinstalled as directed in the [software installation instructions](../../installation/robot.mdx#robot-services).
-## Hosts
+## Hosts {#hosts}
The **hosts** section serves as a way to match hostnames to IP addresses. By default, Clearpath robots use the serial number as
the hostname and have a default IP of `192.168.131.1`. This section must define ip addresses for all hostnames that appear in
@@ -90,7 +90,7 @@ Each server can be defined with a number of different parameters:
| Key | Value / Datatype | Description |
|:---:| :--------------: | ----------- |
-| **hostname** | string | The hostname of the computer that is hosting the server (must be in the [hosts](#Hosts) list). |
+| **hostname** | string | The hostname of the computer that is hosting the server (must be in the [hosts](#hosts) list). |
| **port** | integer | The port at which to connect to the server (default is `11811`). |
| **enabled** | `True` or `False` | This indicates whether or not the robot should connect to this server and, if the hostname matches the computer's own hostname, whether or not to launch the server (default is `True`). |
@@ -104,39 +104,40 @@ servers:
## Sample
-Sample A200 System Section
-
-
-In our sample, we have a **Husky A200** platform whose primary computer has the hostname: `cpr-a200-0000` and IP: `192.168.131.1`.
-
-By default, all Clearpath robots use the username `administrator` and the robot's namespace matches the `serial_number`.
-
-```yaml
-system:
- username: administrator
- hosts:
- - hostname: cpr-a200-0000
- ip: 192.168.131.1
- ros2:
- namespace: a200_0000
- domain_id: 0
- middleware:
- implementation: rmw_fastrtps_cpp
- discovery: simple
- workspaces: []
-```
-
-At this point, with just the **serial_number** and **system** defined, our robot is just the standard **Husky A200** platform, and looks like this:
-
-
-
-
- Default Husky A200
-
-
-
-
+
+ Sample A200 System Section
+
+
+ In our sample, we have a **Husky A200** platform whose primary computer has the hostname: `cpr-a200-0000` and IP: `192.168.131.1`.
+
+ By default, all Clearpath robots use the username `administrator` and the robot's namespace matches the `serial_number`.
+
+ ```yaml
+ system:
+ username: administrator
+ hosts:
+ - hostname: cpr-a200-0000
+ ip: 192.168.131.1
+ ros2:
+ namespace: a200_0000
+ domain_id: 0
+ middleware:
+ implementation: rmw_fastrtps_cpp
+ discovery: simple
+ workspaces: []
+ ```
+
+ At this point, with just the **serial_number** and **system** defined, our robot is just the standard **Husky A200** platform, and looks like this:
+
+
+
+
+ Default Husky A200
+
+
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/installation/controller.mdx b/docs_versioned_docs/version-ros2humble/ros/installation/controller.mdx
index d4ac8cb78..685e99e63 100644
--- a/docs_versioned_docs/version-ros2humble/ros/installation/controller.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/installation/controller.mdx
@@ -73,6 +73,6 @@ The controller should now be paired.
:::note
-Make sure to set the correct controller type in your [robot.yaml](../config/yaml/overview.mdx) file. See, [Joystick Controller](../config/yaml/platform/controller.mdx#joystick-controller) setup in the Clearpath Configuration.
+Make sure to set the correct controller type in your [robot.yaml](../config/yaml/overview.mdx) file. See, [Joystick Controller](../config/yaml/platform/controller.mdx) setup in the Clearpath Configuration.
:::
diff --git a/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx b/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
index e51ddbc42..889bb1641 100644
--- a/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
@@ -167,151 +167,152 @@ sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
### Option 2: Manual Source Install
-Click to expand the manual source install instructions. Only use this option if you
-know what you are doing.
-
+
+ Click to expand the manual source install instructions. Only use this option if you
+ know what you are doing.
+
-#### ROS 2 Humble
+ #### ROS 2 Humble
-Follow the [official instructions](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html)
-for installing ROS 2 Humble from debian packages.
+ Follow the [official instructions](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html)
+ for installing ROS 2 Humble from debian packages.
-#### Clearpath Package Server
+ #### Clearpath Package Server
-The Clearpath package server needs to be added to the robot computer to access robot packages.
+ The Clearpath package server needs to be added to the robot computer to access robot packages.
-Configure Ubuntu's APT package manager to add the package server:
+ Configure Ubuntu's APT package manager to add the package server:
-**1. Install the authentication key for the packages.clearpathrobotics.com repository**
+ **1. Install the authentication key for the packages.clearpathrobotics.com repository**
-```
-wget https://packages.clearpathrobotics.com/public.key -O - | sudo apt-key add -
-```
+ ```
+ wget https://packages.clearpathrobotics.com/public.key -O - | sudo apt-key add -
+ ```
-**2. Add the debian sources for the repository**
+ **2. Add the debian sources for the repository**
-```
-sudo sh -c 'echo "deb https://packages.clearpathrobotics.com/stable/ubuntu $(lsb_release -cs) main" > /etc/apt/sources.list.d/clearpath-latest.list'
-```
+ ```
+ sudo sh -c 'echo "deb https://packages.clearpathrobotics.com/stable/ubuntu $(lsb_release -cs) main" > /etc/apt/sources.list.d/clearpath-latest.list'
+ ```
-**3. Update your computer’s package cache**
+ **3. Update your computer’s package cache**
-```
-sudo apt-get update
-```
+ ```
+ sudo apt-get update
+ ```
-#### Network Configuration
+ #### Network Configuration
-
+
-##### Standard Clearpath Bridge
+ ##### Standard Clearpath Bridge
-
+
-For details on setting up custom network interface settings see [Clearpath Computer Setup](../networking/computer_setup.mdx).
+ For details on setting up custom network interface settings see [Clearpath Computer Setup](../networking/computer_setup.mdx).
-#### Clearpath Robot metapackage
+ #### Clearpath Robot metapackage
-Once the Clearpath package server has been added, the [Clearpath Robot](https://github.com/clearpathrobotics/clearpath_robot)
-metapackage can be installed.
+ Once the Clearpath package server has been added, the [Clearpath Robot](https://github.com/clearpathrobotics/clearpath_robot)
+ metapackage can be installed.
-```
-sudo apt install ros-humble-clearpath-robot
-```
+ ```
+ sudo apt install ros-humble-clearpath-robot
+ ```
-Installing this package will also install all dependencies required to run any Clearpath robot and supported sensors,
-other than Clearpath firmware packages.
+ Installing this package will also install all dependencies required to run any Clearpath robot and supported sensors,
+ other than Clearpath firmware packages.
-#### Source install
+ #### Source install
-**1. Create a workspace on the robot's computer for the clearpath packages**
+ **1. Create a workspace on the robot's computer for the clearpath packages**
-```
-mkdir ~/clearpath_ws/src -p
-```
+ ```
+ mkdir ~/clearpath_ws/src -p
+ ```
-**2. Import dependencies**
+ **2. Import dependencies**
-```
-source /opt/ros/humble/setup.bash
-sudo apt install python3-vcstool
-cd ~/clearpath_ws
-wget https://raw.githubusercontent.com/clearpathrobotics/clearpath_robot/main/dependencies.repos
-vcs import src < dependencies.repos
-cd ~/clearpath_ws/src
-git clone https://github.com/clearpathrobotics/clearpath_robot.git
-cd ~/clearpath_ws
-rosdep install -r --from-paths src -i -y
-```
+ ```
+ source /opt/ros/humble/setup.bash
+ sudo apt install python3-vcstool
+ cd ~/clearpath_ws
+ wget https://raw.githubusercontent.com/clearpathrobotics/clearpath_robot/main/dependencies.repos
+ vcs import src < dependencies.repos
+ cd ~/clearpath_ws/src
+ git clone https://github.com/clearpathrobotics/clearpath_robot.git
+ cd ~/clearpath_ws
+ rosdep install -r --from-paths src -i -y
+ ```
-**3. Build packages**
+ **3. Build packages**
-```
-colcon build --symlink-install
-```
+ ```
+ colcon build --symlink-install
+ ```
-**4. Link the workspace**
+ **4. Link the workspace**
-Add the following line to your `~/clearpath_ws/src/clearpath_robot/clearpath_robot/scripts/generate` file,
-right under where ROS is sourced:
+ Add the following line to your `~/clearpath_ws/src/clearpath_robot/clearpath_robot/scripts/generate` file,
+ right under where ROS is sourced:
-```
-source /home/administrator/clearpath_ws/install/setup.bash
-```
+ ```
+ source /home/administrator/clearpath_ws/install/setup.bash
+ ```
-:::note
+ :::note
-This workspace will also need to be sourced in your [robot.yaml](#robot-yaml) file as described
-in the [ROS2 Environment](../config/yaml/system.mdx#ros-2-environment) section.
+ This workspace will also need to be sourced in your [robot.yaml](#robot-yaml) file as described
+ in the [ROS2 Environment](../config/yaml/system.mdx#ros-2-environment) section.
-:::
+ :::
-#### Setup folder
+ #### Setup folder
-Create the setup folder where the [robot.yaml](../config/yaml/overview.mdx) file will be stored, and where files will be generated:
+ Create the setup folder where the [robot.yaml](../config/yaml/overview.mdx) file will be stored, and where files will be generated:
-```
-sudo mkdir /etc/clearpath/ -p && sudo chmod 777 /etc/clearpath/
-```
-#### Robot YAML
+ ```
+ sudo mkdir /etc/clearpath/ -p && sudo chmod 777 /etc/clearpath/
+ ```
+ #### Robot YAML
-The `robot.yaml` file defines the configuration of the robot including the robot model, all
-supported accessories and any extra URDF elements or ROS parameters. Information about the Robot YAML
-is found in the [Robot Configuration](../config/yaml/overview.mdx) section. This YAML is used to generate the launch,
-URDF and ROS parameter files during runtime.
+ The `robot.yaml` file defines the configuration of the robot including the robot model, all
+ supported accessories and any extra URDF elements or ROS parameters. Information about the Robot YAML
+ is found in the [Robot Configuration](../config/yaml/overview.mdx) section. This YAML is used to generate the launch,
+ URDF and ROS parameter files during runtime.
-Create your `robot.yaml` file and then copy it into `/etc/clearpath/`.
+ Create your `robot.yaml` file and then copy it into `/etc/clearpath/`.
-#### Robot services
+ #### Robot services
-Clearpath robot services can now be installed with the following command:
+ Clearpath robot services can now be installed with the following command:
-```
-source /opt/ros/humble/setup.bash
-ros2 run clearpath_robot install
-sudo systemctl enable clearpath-robot
-```
+ ```
+ source /opt/ros/humble/setup.bash
+ ros2 run clearpath_robot install
+ sudo systemctl enable clearpath-robot
+ ```
-This script uses [robot_upstart](https://github.com/clearpathrobotics/robot_upstart/tree/foxy-devel) to install the `systemd` services
-that will launch platform and sensor launch files as background processes.
+ This script uses [robot_upstart](https://github.com/clearpathrobotics/robot_upstart/tree/foxy-devel) to install the `systemd` services
+ that will launch platform and sensor launch files as background processes.
-To start the services, call
+ To start the services, call
-```
-sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
-```
+ ```
+ sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
+ ```
-Add the following line to your `~/.bashrc` file to automatically source the generated `setup.bash` file in new terminals:
+ Add the following line to your `~/.bashrc` file to automatically source the generated `setup.bash` file in new terminals:
-```
-source /etc/clearpath/setup.bash
-```
+ ```
+ source /etc/clearpath/setup.bash
+ ```
-#### Additional settings
+ #### Additional settings
-Certain sensors may require additional setup, please review the [Accessories](../../robots/accessories/accessories.mdx) pages
-for any additional instructions for the sensors that you are using. For example, the Blackfly camera has additional instructions
-listed under [software bringup](../../robots/accessories/sensors/cameras/flir_blackfly_s#software-bringup).
-
+ Certain sensors may require additional setup, please review the [Accessories](../../robots/accessories/accessories.mdx) pages
+ for any additional instructions for the sensors that you are using. For example, the Blackfly camera has additional instructions
+ listed under [software bringup](../../robots/accessories/sensors/cameras/flir_blackfly_s#software-bringup).
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/networking/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/networking/overview.mdx
index ae682cfd4..5df49d603 100644
--- a/docs_versioned_docs/version-ros2humble/ros/networking/overview.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/networking/overview.mdx
@@ -59,4 +59,4 @@ For details on configuring `chrony`, please see [configuring NTP](ntp.mdx).
### Network Troubleshooting
-There are many things that can go wrong when setting up ROS 2 networking. To aid in this process, a [troubleshooting section](./network_troubleshooting/troubleshooting_overview.mdx) is available with flowcharts to guide the process of troubleshooting two computers that are not communicating properly as well as discussion of common issues that can cause intermittent or unreliable communication. A list and description of troubleshooting tools is also available to assist in the troubleshooting process.
\ No newline at end of file
+There are many things that can go wrong when setting up ROS 2 networking. To aid in this process, a [troubleshooting section](./network_troubleshooting/troubleshooting_overview.mdx) is available with flowcharts to guide the process of troubleshooting two computers that are not communicating properly as well as discussion of common issues that can cause intermittent or unreliable communication. A list and description of troubleshooting tools is also available to assist in the troubleshooting process.
diff --git a/docs_versioned_docs/version-ros2humble/ros/networking/wifi_fundamentals.mdx b/docs_versioned_docs/version-ros2humble/ros/networking/wifi_fundamentals.mdx
index 1f2f03a87..460f786a8 100644
--- a/docs_versioned_docs/version-ros2humble/ros/networking/wifi_fundamentals.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/networking/wifi_fundamentals.mdx
@@ -45,7 +45,7 @@ It is important to understand that on the 2.4 GHz band, adjacent channels are ov
The choice of channels and channel widths depends very much on the type of network being designed. The recommendations discussed in this section are for specific robot configurations and may run counter to recommendations for configuring enterprise networks. This is because the goals, restrictions and priorities of these systems are different. Do note that if the router is using the same Wi-Fi radio to broadcast a network and to connect to another Wi-Fi network as a client (for Wi-Fi as WAN), then both networks must use the same channel and channel width.
-In an outdoor system where there is one access point servicing a small number of robots (<10) and relatively little interference, the focus is on throughput. To maximize this throughput the channel should be chosen for the lowest interference and the channel width should be wide (80 MHz on 5 GHz and 40 MHz on 2.4 GHz). Functionally, it is often best to allow the router to automatically choose the channel and channel width. It will evaluate the best options based on evaluating interference in the immediate area. If the router does not support dynamic channel selection, then interference can be evaluated using a Wi-Fi analyzer phone app and an available channel with the least interference can be selected. This method will not catch non-Wi-Fi devices that share the same frequencies, however it is a good guide, particularly at 5 GHz. It is valuable to note that some devices have to decrease the transmit power to support larger channel widths. Whether this is a problem is something that should be evaluated by testing empirically with the devices in the operating area.
+In an outdoor system where there is one access point servicing a small number of robots (less than 10) and relatively little interference, the focus is on throughput. To maximize this throughput the channel should be chosen for the lowest interference and the channel width should be wide (80 MHz on 5 GHz and 40 MHz on 2.4 GHz). Functionally, it is often best to allow the router to automatically choose the channel and channel width. It will evaluate the best options based on evaluating interference in the immediate area. If the router does not support dynamic channel selection, then interference can be evaluated using a Wi-Fi analyzer phone app and an available channel with the least interference can be selected. This method will not catch non-Wi-Fi devices that share the same frequencies, however it is a good guide, particularly at 5 GHz. It is valuable to note that some devices have to decrease the transmit power to support larger channel widths. Whether this is a problem is something that should be evaluated by testing empirically with the devices in the operating area.
In a system where there needs to be multiple access points to service many robots in the same area, it is important to select channels and channel widths so that the different access points are not causing interference for each other. In this case, automatic channel selection and channel width selection would be undesirable.
diff --git a/docs_versioned_docs/version-ros2humble/ros/tutorials/manipulation/gazebo.mdx b/docs_versioned_docs/version-ros2humble/ros/tutorials/manipulation/gazebo.mdx
index 75b478cdf..52b564f4c 100644
--- a/docs_versioned_docs/version-ros2humble/ros/tutorials/manipulation/gazebo.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/tutorials/manipulation/gazebo.mdx
@@ -12,7 +12,8 @@ In this tutorial, we will cover using the MoveIt! Planning and Execution RViz pl
The `robot.yaml` configuration we will use is included below.
-A200 YAML
+
+A200 YAML
```yaml
diff --git a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/localization.mdx b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/localization.mdx
index 02e1d125f..92153cbdf 100644
--- a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/localization.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/localization.mdx
@@ -13,67 +13,68 @@ laser scan data from a 2D LIDAR, and the robot's odometry. For this demo we are
This tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical
robot too. We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
-J100 YAML
-
:::tip
diff --git a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/nav2.mdx b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/nav2.mdx
index 644d02bae..e56c916c0 100644
--- a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/nav2.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/nav2.mdx
@@ -12,67 +12,68 @@ provides default configurations for supported robots, but these can be customize
tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical robot too.
We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
-J100 YAML
-
:::tip
diff --git a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/slam.mdx b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/slam.mdx
index 551913108..3b5456a0b 100644
--- a/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/slam.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/tutorials/navigation_demos/slam.mdx
@@ -13,67 +13,66 @@ laser scan data from a 2D LIDAR, and the robot's odometry. For this demo we are
This tutorial will use the [Clearpath simulator](../simulator/overview.mdx), but will work on a physical
robot too. We will be using a J100 with a Hokuyo UST10 attached to the front of the robot.
-J100 YAML
-
+
+ 
+ 
+ 
+ 
+ 
+ ![]({require("./img/bumper.png").default})
+![]({require("./img/sensor_arch_300.png").default})
+![]({require("./img/sensor_arch_510.png").default})
+![]({require("./img/top_plate_default.png").default})
+![]({require("./img/top_plate_large.png").default})
+![]({require("./img/top_plate_pacs.png").default})
+![]({require("./img/top_plate_dd100.png").default})
+![]({require("./img/top_plate_dd150.png").default})
+![]({require("./img/top_plate_do1X0.png").default})
+![]({require("./img/fender_default.png").default})
+![]({require("./img/fender_sensor.png").default})
+![]({require("./img/top_plate_ark_enclosure.png").default})
+![]({require("./img/fams.png").default})
+![]({require("./img/hams.png").default})
+![]({require("./img/tower.png").default})
+![]({require("./img/arm_mount.png").default})
+![]({require("./img/bulkhead_arm_mount.png").default})
+![]({require("./img/bulkhead_default.png").default})
+![]({require("./img/generator.png").default})
+![]({require("./img/box.png").default})
+![]({require("./img/cylinder.png").default})
+![]({require("./img/frame.png").default})
+![]({require("./img/mesh.png").default})
+![]({require("./img/sphere.png").default})
+![]({require("./img/kinova_2f_lite.png").default})
+![]({require("./img/kinova_gen3_6dof.png").default})
+![]({require("./img/kinova_gen3_7dof.png").default})
+![]({require("./img/kinova_gen3_lite.png").default})
+![]({require("./img/robotiq_2f_140.png").default})
+![]({require("./img/robotiq_2f_85.png").default})
+![]({require("./img/bracket_horizontal.png").default})
+![]({require("./img/bracket_large.png").default})
+![]({require("./img/bracket_vertical.png").default})
+![]({require("./img/disk.png").default})
+![]({require("./img/disk_post.png").default})
+![]({require("./img/fath_pivot.png").default})
+![]({require("./img/post_dual.png").default})
+![]({require("./img/post_quad.png").default})
+![]({require("./img/post_single.png").default})
+![]({require("./img/riser_1x7.png").default})
+![]({require("./img/riser_4x4.png").default})
+![]({require("./img/riser_8x7.png").default})
+![]({require("./img/sick_inverted.png").default})
+![]({require("./img/sick_upright.png").default})
+![]({require("./img/chrobotics_um6.png").default})
+![]({require("./img/flir_blackfly.png").default})
+![]({require("./img/garmin_18x.png").default})
+![]({require("./img/hokuyo_ust.png").default})
+![]({require("./img/intel_realsense.png").default})
+![]({require("./img/microstrain_gq7.png").default})
+![]({require("./img/microstrain_imu.png").default})
+![]({require("./img/novatel_smart6.png").default})
+![]({require("./img/novatel_smart7.png").default})
+![]({require("./img/redshift_um7.png").default})
+![]({require("./img/sick_lms1xx.png").default})
+![]({require("./img/stereolabs_zed.png").default})
+![]({require("./img/swiftnav_duro.png").default})
+![]({require("./img/velodyne_lidar.png").default})
+
+ 
+ 
+
+
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+ 
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+ 
+ 
+ 
+ 
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+
+
+ 
+
+ 
+
+
+
+
+
+ 
+ 
+ 
+ 
+
+
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
| **Motion Stop button**: LED is solid green when Dingo is able to drive and is flashing green when the Dingo's motors are disengaged; pressing button toggles the motors between engaged and disengaged mode (further details in [Motion Stop Buttons](#dingo-stop-buttons)); LED is not illuminated when connected to DC shore power or to the wired charger (as the robot is prevented from moving in this state) |
+| 
| **Comms indictor**: LED is solid green when communication between the MCU and computer has been established and LED is off otherwise |
+| 
| **Wi-Fi indicator**: LED is solid green when Wi-Fi is connected and LED is off otherwise |
+| 
| **Battery indicator**: LED is solid green when the battery level is ok, flashing green when connected to DC shore power, solid yellow when the battery level is getting low (should be charged soon), and solid red when the battery level is critical (should be charged immediately) |
+| 
| **System Power button**: LED is solid blue when the system is powered on and running and the LED is flashing blue during the shutdown process; when the system is powered off, pressing the power button begins the power on process; when the system is powered on, a quick press of the power button begins a graceful shutdown and a prolonged press of the power button triggers and immediate power off of the system |
+
+
+ 
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
| 
+ 
+
+
+
+
+
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
| **Battery Status** The four LED segments provide an approximate indication of the relative lifetime remaining in the battery. |
+| 
| **Communication Status** When green, Husky is receiving a stream of correctly-formatted motion commands, and is ready to drive. When yellow, Husky is receiving commands, but will not drive due to emergency stop or another error. When red, serial communications are currently timed-out. |
+| 
| **General Error Status** Illuminates red when Husky will not drive due to an error state. Such states include emergency stop, insufficient battery power, or an unspecified software error. |
+| 
| **Emergency Stop Status** Illuminates red when Husky will not drive due to the emergency stop being activated, either onboard or wireless (if available). |
+| 
| **Charge Indicator** Illuminates red when Husky user power is being supplied externally. |
+
+#### Buttons and Lockouts
+
+The silver button at the top of the Status Panel is used to power the Husky on and off. From the "off" state, pressing the button
+will cause the Husky to power on and a blue ring at the edge of the button will be illuminated. From the "on" state, pressing
+the button will cause the Husky to power off and the blue ring will no longer be illuminated.
+
+See [Stop button and Lockout](#husky-stop-button-and-lockout) for details of the Stop button and Lockout.
+
+#### Payloads
+
+Additional payloads such IMUs, lidars, cameras, GPS, manipulators and many more can be integrated with Husky, either as part of your Husky purchase or installed after receiving your Husky.
+You can find a list of supported packages and related documentation for payloads in this documention portal, under the [Computers](../../../accessories/computers/computers.mdx),
+[Sensors](../../../accessories/sensors/sensors.mdx), [Manipulators](../../../accessories/manipulators/manipulators.mdx), and [Accessories](../../../accessories/add-ons/add-ons.mdx) sections.
+In addition, refer to [Husky Integration](integration_husky/integration_husky.mdx) for details on how to integrate your own payload or how to integrate a payload kit from Clearpath Robotics.
+Each payload kit that ships from Clearpath Robotics comes with a custom mounting bracket and cabling for easy attachment to Husky.
+
+#### Orientation References
+
+The reference frame used by all Clearpath Robotics ground robots is based on ISO 8855, and is shown in the figure below.
+Husky's front is shown.
+When commanded with a positive translational velocity (forward), wheels travel in the positive X-direction.
+The direction of the axes differs from those used for roll, pitch, and yaw in aircraft, and care should be taken to ensure that data is interpreted correctly.
+
+
+
+
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
| An error has been detected with the battery. Please contact support. |
+| Motor Fault | Flashing red at the corner with the motor fault; solid red for the other corners. | An error has been detected with the motor or its controller. Please contact support. |
+| Charged | 
| The robot's batteries are charged fully. Shore power is available for the robot to operate (excluding drive motors). |
+| Charging (wired or wireless) | 
| The robot's batteries are being charged, either from the wired/manual charger or the wireless charger. This also provides shore power for the robot to operate (excluding drive motors). |
+| Emergency Stop Engaged | 
| Emergency Stop mode is engaged. To disengage, twist both red mushroom buttons on the robot to ensure that they are unlatched and press the Safety Restart button. |
+| Needs Safety Restart (after Emergency Stop) | 
| The Emergency Stop buttons have been disengaged but the Safety Restart button still needs to be pressed to resume driving. |
+| Motor Protection Engaged | Solid magenta | Motor velocity is being limited due to high currents or high temperatures. |
+| Low Battery | 
| The robot's batteries are in a low charge state. Connect the robot to a charger. |
+| Driving | 
| The robot is driving (normal operation). |
+| Idle | 
| The robot is idle (normal operation). |
+
+#### Buttons
+
+##### Emergency Stop Buttons {#emergency-stop-buttons}
+
+The Husky is equipped with two Emergency Stop buttons, one at the front and one at the rear. Pressing either of
+these buttons removes power from the drivetrain. To clear the stop condition, all Emergency Stop buttons must
+be disengaged and the Safety Restart Button must be pressed. Refer to [Emergency Stops](#husky-emergency-stop-button) for more details.
+
+##### Safety Restart Button {#restart-button}
+
+To clear the stop condition, all Emergency Stop buttons must be disengaged and the Safety Restart Button must be pressed.
+Refer to [Emergency Stops](#husky-emergency-stop-button) for more details.
+
+Pressing the Safety Restart Button will have no effect when not in the stop condition or when one or more Emergency Stop
+buttons are engaged.
+
+##### Power Button
+
+The Power button is used to power the robot on and off. From the "OFF" state, pressing
+the button will cause the robot to power on. From the "ON" state, pressing the button will cause the robot to power off.
+Note that the Power button has no effect when the Battery Breaker is in the "OFF" position, unless
+a charger is connected to the robot.
+
+#### Protected Access Panel
+
+The rear of the robot has an access panel, protected by a Lock-Out, that contains the Battery Charge Port, Battery Breaker,
+Debug Ports, and Wireless Emergency Stop Bypass. Opening the access panel cover puts the robot into a stop condition to
+prevent the robot from driving while cables may be connected. To clear the stop condition, close the access panel cover
+and press the Safety Restart Button.
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
+ 
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ ![]({require("/img/robot_images/common_images/lighting_images/battery_fault.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/shore_fault.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/shore_and_charged.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/shore_and_charging.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/shore_power.png").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/charged.png").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/charging.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/stopped.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/needs_reset.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/low_battery.gif").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/driving.png").default})
+ ![]({require("/img/robot_images/common_images/lighting_images/idle.png").default})
+ ![]({require("./img/live_yaml.gif").default})
+ ![]({require("../img/husky_platform_2.png").default})
+ ![]({require("../img/husky_accessories_0.png").default})
+ ![]({require("../img/husky_mounts_0.png").default})
+ ![]({require("../img/husky_mounts_1.png").default})
+ ![]({require("../img/husky_sample.png").default})
+ ![]({require("../../img/husky_platform_0.png").default})
+ ![]({require("../../img/husky_platform_1.png").default})
+ ![]({require("../../img/husky_platform_2.png").default})
+ ![]({require("../../img/husky_mounts_1.png").default})
+ ![]({require("../../img/husky_sensors_0.png").default})
+ ![]({require("../../img/husky_sensors_1.png").default})
+ ![]({require("../../img/husky_sensors_2.png").default})
+ ![]({require("../img/husky_platform_0.png").default})
+ ![]({require("./img/wifi_interface.jpg").default})
+ ![]({require("./img/network-integrity-troubleshooting-flowchart.png").default})
+ ![]({require("./img/ros2-comms-troubleshooting-flowchart.png").default})
+ ![]({require("./img/ros2-fastdds-simple-discovery-diagram.png").default})
+ ![]({require("./img/ros2-fastdds-discovery-server-diagram.png").default})
+ ![]({require("./img/ros2-fastdds-fully-connected-diagram.png").default})
+ ![]({require("./img/ros2-fastdds-command-center-diagram.png").default})
+ ![]({require("./img/moveit_gazebo.gif").default})
+ ![]({require("./img/localization.gif").default})
+ ![]({require("./img/nav2.gif").default})
+ ![]({require("./img/slam.gif").default})
+ ![]({require("./img/simulation.png").default})
+ ![]({require("./img/driving.gif").default})
+ ![]({require("./img/battery_fault.gif").default})
![]({require("./img/shore_fault.gif").default})
![]({require("./img/shore_and_charged.gif").default})
![]({require("./img/shore_and_charging.gif").default})
![]({require("./img/shore_power.png").default})
![]({require("./img/charged.png").default})
![]({require("./img/charging.gif").default})
![]({require("./img/stopped.gif").default})
![]({require("./img/needs_reset.gif").default})
![]({require("./img/low_battery.gif").default})
![]({require("./img/driving.png").default})
![]({require("./img/idle.png").default})