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/yaml.mdx b/docs/ros/config/yaml.mdx
index bd6b89f0c..267882bac 100644
--- a/docs/ros/config/yaml.mdx
+++ b/docs/ros/config/yaml.mdx
@@ -6,3 +6,963 @@ 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 information pertinent to the entire robot system, allowing robot builders and users to quickly and easily modify any ROS 2 component.
+
+## Overview
+
+The `robot.yaml` is composed of five major sections:
+
+1. [**system**](#system) level information such as the robot's hostname, IP, and ROS middleware implementation.
+2. [**platform**](#platform) level configurations such as robot specific mounting structures and specifying an extra URDF to attach.
+3. [**accessories**](#accessories) that are URDF primitives: boxes, cylinders, and meshes.
+4. [**mounts**](#mounts) that are predefined, generic, sensor mounting structures.
+5. [**sensors**](#sensors) that are selected from an inventory of Clearpath supported sensors.
+
+Additionally, there are two other, required parameters:
+
+1. The robot's [**serial_number**](#serial-number); 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.
+
+You can also skip to each section to get an explanation of each part of the sample configuration:
+
+1. [**Serial Number Sample**](#serial-sample)
+2. [**System Sample**](#system-sample)
+3. [**Platform Sample**](#platform-sample)
+4. [**Accessories Sample**](#accessories-sample)
+5. [**Mounts Sample**](#mounts-sample)
+6. [**Sensors Sample**](#sensors-sample)
+
+Sample A200 YAML
+
+
+
+## Serial Number
+
+The Clearpath serial number is composed of two sections: an alpha-numerical code corresponding to the robot platform, followed by an integer corresponding to the unit number, and separated by a hyphen, `-`. e.g. `a200-0001`.
+
+At this moment, the supported robot platforms are:
+
+1. [Husky A200](../../robots/outdoor_robots/husky/user_manual_husky/#introduction): `a200-0000`
+2. [Jackal J100](../../robots/outdoor_robots/jackal/user_manual_jackal/#introduction): `j100-0000`
+
+Every robot platform has specific [decorations](#decorations), i.e. platform specific parts, that are selected based on the serial number passed. Therefore, it is required that a serial number is specified in the `robot.yaml`.
+
+### Sample {#serial-sample}
+
+In our sample, we use a **Husky A200** and therefore have set our serial number to:
+
+```yaml
+serial_number: "a200-0000"
+```
+
+## System
+
+Proper networking setup is crucial in setting up the ROS 2 middleware and ensure other onboard computers communicate reliably.
+
+### Hosts
+
+The **hosts** section serves as a way to match IP addresses to hostnames. By default, Clearpath robots use the serial number as the hostname and have a default IP of `192.168.131.1`.
+
+- The **self** entry refers to what hostname is this configuration file on.
+- The **platform** entry refers to the hostname and IP of the robot platform's main computer.
+- The **onboard** entry is used to define the hostname and IP of other computers on the robot.
+- The **remote** entry is used to define the hostname and IP of computers in the system that are not on the robot, such as a user's PC.
+
+### ROS 2 Environment
+
+The **ros2** sections is necessary to setup the ROS 2 middleware.
+
+- **username** must match the username of the user that is to run all ROS nodes.
+- **namespace** specified will be appended as a prefix to all sensor topics to prevent topic cloberring when multiple robots are on the same network and domain ID.
+- **domain_id** specifies the ROS 2 domain ID to use.
+- **rmw_implementation** specifies the ROS 2 middleware to use. **Currently, it only supports `rmw_fastrtps_cpp`.**
+
+### Sample {#system-sample}
+
+Sample A200 System Section
+
+
+In our sample, we have a **Husky A200** platform whose primary computer has hostname: `cpr-a200-0000` and IP: `192.168.131.1`.
+
+And, note that this configuration YAML is meant to be on that primary computer, hence `self: cpr-a200-0000`.
+
+By default, all Clearpath robots use username `administrator` and the robot's namespace matches the `serial_number`.
+
+```yaml
+system:
+ hosts:
+ self: cpr-a200-0000
+ platform:
+ cpr-a200-0000: 192.168.131.1
+ onboard: {}
+ remote: {}
+ ros2:
+ username: administrator
+ namespace: a200_0000
+ domain_id: 0
+ rmw_implementation: rmw_fastrtps_cpp
+```
+
+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
+
+
+
+
+
+
+## Platform
+
+Every robot platform has unique structures such as versatile sensor mounting solutions, wireless charging receivers, and waterproofing enclosures; we refer to these as decorations.
+
+#### Decorations
+
+There are three types of decorations:
+
+1. **bumpers** modify the front and rear of the robot platform.
+2. **top_plates** modify the top of the robot platform.
+3. **structures** are large custom parts that are added atop the top plate.
+
+#### Husky A200 {#decorations-a200}
+
+The **Husky A200** has a few models for each of it's decorations:
+
+- **bumpers**:
+ - **_default:_** standard bumpers.
+ - **_wibotic:_** wireless charging receiver.
+
+```yaml
+front_bumper:
+ enabled: true
+ model: default # or wibotic
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+rear_bumper:
+ enabled: true
+ model: default # or wibotic
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+```
+
+- **top plate**:
+ - **_default:_** standard Husky A200 top plate.
+ - **_large:_** extended top plate, used to allow for enough space to mount large payloads.
+ - **_pacs:_** comes with **80x80 mm** mounting screw holes for versatile sensor placement.
+
+```yaml
+top_plate:
+ enabled: true
+ model: default # or 'pacs' or 'large'
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+```
+
+- **struture**:
+ - **_sensor_arch_300:_** 300mm tall extrusion sensor arch.
+ - **_sensor_arch_510:_** 510mm tall extrusion sensor arch.
+
+```yaml
+structure:
+ enabled: false
+ model: sensor_arch_300 # or sensor_arch_510
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+```
+
+#### Jackal J100 {#decorations-j100}
+
+The **Jackal J100** currently only has customization options with it's fenders.
+
+- **bumpers**, which correspond to the fenders, can be enabled and disabled.
+
+```yaml
+front_bumper:
+ enabled: true # or false
+ model: default
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+rear_bumper:
+ enabled: true # or false
+ model: default
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+```
+
+#### Extras
+
+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.
+Extras have the following entries:
+
+- **urdf:** absolute path to URDF to add to robot platform URDF.
+- **config:** absolute path to ROS parameters to load for all robot platform nodes, e.g. overwrite control, teleop, and localization parameters.
+
+```yaml
+extras:
+ urdf: null # /absolute/path/to/urdf
+ control: null # /absolute/path/to/ros_parameters
+```
+
+#### Sample {#platform-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
+top_plate:
+ enabled: true
+ model: pacs # switched from 'default' to 'pacs'
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+```
+
+
+
+
+ Husky A200 with PACS Top Plate
+
+
+
+Then, we added a sensor arch to add our sample sensors to. We can do this by simply enabling the **structure** and setting the model to **_sensor_arch_300_**.
+
+```yaml
+structure:
+ enabled: true
+ model: sensor_arch_300
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+```
+
+
+
+
+ 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:
+ controller: ps4
+ decorations:
+ front_bumper:
+ enabled: true
+ model: default
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+ rear_bumper:
+ enabled: true
+ model: default
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extension: 0.0
+ structure:
+ enabled: true
+ model: sensor_arch_300
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ top_plate:
+ enabled: true
+ model: pacs
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ extras:
+ urdf: null
+ control: null
+```
+
+
+
+
+## Accessories
+
+Accessories are any URDF primitive:
+
+1. **link** in the URDF without any geometry, i.e. just a frame.
+
+```yaml
+link:
+ - name: link_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+```
+
+2. **box** of given length, width, and height.
+
+```yaml
+box:
+ - name: box_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ size: [0.01, 0.01, 0.01]
+```
+
+3. **cylinder** of given radius and height.
+
+```yaml
+cylinder:
+ - name: cylinder_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ radius: 0.01
+ length: 0.01
+```
+
+4. **sphere** of given radius.
+
+```yaml
+sphere:
+ - name: sphere_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ radius: 0.01
+```
+
+5. **mesh** from a given absolute path to STL or OBJ file.
+
+```yaml
+mesh:
+ - name: mesh_name
+ parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ visual: /absolute/path/to/mesh.stl
+```
+
+If a user needs to add a mesh or primitive to represent a payload on their robot, they can either create a URDF and use the platform extras, or they can add an accessory directly through the `robot.yaml`.
+
+Just as is the case in URDF, accessories are added at the center of the primitive. In other words, you will need to slide up all accessories by half their height to have it "sit" on its parent link.
+
+### Sample {#accessories-sample}
+
+Sample A200 Accessories Section
+
+
+
+
+
+ Husky A200 with Open User Bay
+
+
+
+In this sample, we will use accessories 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 accessories section:
+
+```yaml
+accessories:
+ 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: []
+ link: []
+ mesh: []
+ sphere: []
+```
+
+
+
+
+## Mounts
+
+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.
+
+The following **mounts** are available:
+
+- **riser:** a plate with the defined number of rows and columns of an **80mm x 80mm** grid.
+
+```yaml
+riser:
+ - parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ rows: 4 # rows of 80mm x 80mm grid
+ columns: 4 # columns of 80mm x 80mm grid
+ thickness: 0.00635
+```
+
+- **bracket:** a small **100mm x 100mm** plate with **80mm x 80mm** screw holes to attach it to the grid. It comes with hole patterns to attach all supported small sensors.
+
+```yaml
+bracket:
+ - parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ model: horizontal # or large or vertical
+```
+
+- **fath_pivot:** generally a camera mount on a single axis that can be adjusted to change the pitch of the camera.
+
+```yaml
+fath_pivot:
+ - parent: base_link
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ angle: 0.0 # in radian
+```
+
+### Sample {#mounts-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_**, i.e. the middle (**d**), front (**1**), 80mm x 80mm 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 21mm 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
+
+
+
+
+ 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:
+ frame_id: lidar3d_0_laser
+ device_ip: 192.168.131.25
+ port: 2368
+ 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_ust10` 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_ust10
+ 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:
+ laser_frame_id: lidar2d_0_laser
+ ip_address: 192.168.131.20
+ ip_port: 10940
+ angle_min: -3.141592653589793
+ angle_max: 3.141592653589793
+```
+
+
+
+
+ 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:
+ 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
+```
+
+
![]({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_accessories_0.png").default})
+ ![]({require("./img/husky_mounts_0.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})
+