diff --git a/docs/robots/accessories/pacs.mdx b/docs/robots/accessories/pacs.mdx
index 399b1923..bb79aa2e 100644
--- a/docs/robots/accessories/pacs.mdx
+++ b/docs/robots/accessories/pacs.mdx
@@ -81,7 +81,7 @@ Refer to the integration pages for our robots for more details:
| | [Axis M5525-E](./sensors/cameras/axis_m5525_e) | 006758 | 027106 | 027225 | No |
| | [FLIR Blackfly S](./sensors/cameras/flir_blackfly_s) | many | 027118 | 027218 | Yes |
| | [FLIR Ladybug5+](./sensors/cameras/flir_ladybug5p) | 017245 | 028894 | 028893 | No |
-| | [Intel RealSense D435](./sensors/cameras/realsense_d435) | 024150 | 026869 | 027208 | Yes |
+| | [Intel RealSense D435](./sensors/cameras/realsense_d435) | 017103 | 026869 | 027208 | Yes |
| | [Occam Omni 60 Colour](./sensors/cameras/occam_omni_60) | 019645 | 027102 | 027211 | No |
| | [Stereolabs ZED 2](./sensors/cameras/stereolabs_zed_2) | 023611 | 028960 | 028959 | No |
| | [Stereolabs ZED 2i](./sensors/cameras/stereolabs_zed_2) | 025844 | 026872 | 027210 | No |
diff --git a/docs/robots/accessories/sensors/cameras/realsense_d435.mdx b/docs/robots/accessories/sensors/cameras/realsense_d435.mdx
index af9ca3ca..197db81d 100644
--- a/docs/robots/accessories/sensors/cameras/realsense_d435.mdx
+++ b/docs/robots/accessories/sensors/cameras/realsense_d435.mdx
@@ -16,7 +16,7 @@ import Support from "/components/support.mdx";
| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
| :-------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
-| Intel RealSense D435 sensor | [024150](/assets/pdf/clearpath_robotics_024150-TDS1.pdf) | 026869 | 027208 |
+| Intel RealSense D435 sensor | [017103](/assets/pdf/clearpath_robotics_017103-TDS1.pdf) | 026869 | 027208 |
---
@@ -57,8 +57,8 @@ This allows you to add or remove the sensor from your robot's software descripti
## Further Reading
1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/intel-realsense-d435)
-2. [Datasheet](/assets/pdf/clearpath_robotics_024150-TDS1.pdf)
-3. [Dimensions](/assets/pdf/clearpath_robotics_024150-TDS3.pdf)
-4. [User Manual](/assets/pdf/clearpath_robotics_024150-TDS2.pdf)
+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/outdoor_robots/husky/integration_husky/integration_husky.mdx b/docs/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
index 2113014a..6449367c 100644
--- a/docs/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
+++ b/docs/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
@@ -185,7 +185,7 @@ Contact [Support](#support) for details.
:::caution
This is a single channel Stop loop, being monitored by a microcontroller.
-The when the microcontroller is in a Stop state; it will open relays which supply power to the Husky's motor controllers.
+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.
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
index dee19477..afbf9a74 100644
--- 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
@@ -25,7 +25,7 @@ Refer to the [Extrusion Rails](./extrusion_rails_warthog) page for further detai
| Description | Sales Kit |
| :--------------------------------------------- | :-------: |
-| Installation—Extrusion Cross-Bar, 25 X 50, 655 | 028455 |
+| Installation—Extrusion Cross-Bar, 25 X 50, 652 | 028455 |
## Parts List
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
index 3f38dd33..3fe3dc84 100644
--- 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
@@ -16,10 +16,10 @@ The extrusions are attached to the Warthog using M6×1 stainless steel screws, a
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) | |
+| 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) |
@@ -71,7 +71,7 @@ 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 8 Blocks per beam if your application requires a stiffer base.
+You can install up to 7 Blocks per beam if your application requires a stiffer base.
:::
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
index 70e7cd3e..70a49bed 100644
--- 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
@@ -12,18 +12,6 @@ sidebar_position: 3
The top plates for the Warthog include M5×0.8 threaded holes that match the Clearpath PACS™ standard.
-:::note
-
-These top plates require [extrusion rails](./extrusion_rails_warthog) to be mounted on the Warthog.
-
-:::
-
-:::note
-
-You can install an [extrusion cross-bar](./extrusion_crossbar_warthog) under the top plates to add stiffness.
-
-:::
-
---
## Sales Kits
@@ -48,11 +36,12 @@ Refer to the [Crossbar](./extrusion_crossbar_warthog) page for further details.
## 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 14, Stainless Steel | 023471 | 9 |
+| 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
@@ -78,7 +67,7 @@ Place the Plate _(ID1)_ ontop of the Extrusion Rails and Crossbar. The Plate's c
### Step 3
-Install Screws _(ID3)_ into the Plate's holes; threading the Screws into the T-slop nuts from _Step 1_.
+Install Screws _(ID3)_ and _(ID4)_ into the Plate's holes; threading the Screws into the T-slot nuts from _Step 1_.
:::note
diff --git a/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx b/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
index 5fdb7ca3..dea5fe4b 100644
--- a/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
+++ b/docs_outdoornav_user_manual/api/api_endpoints/definitions.mdx
@@ -167,6 +167,135 @@ clearpath_navigation_msgs/Waypoint[] waypoints
clearpath_navigation_msgs/Task[] tasks
```
+#### clearpath_mission_scheduler_msgs/msg/NextSchedule.msg
+
+```
+# The ID of the next schedule to start
+# Empty if nothing is scheduled
+string uuid
+
+# The time until the schedule starts (rounded to the nearest second)
+duration time_to_start
+```
+
+#### clearpath_mission_scheduler_msgs/msg/Schedule {#scheduler-schedule}
+
+```
+# Single-execution mode; the schedule starts at the designated time and runs once
+uint8 MODE_ONCE=0
+
+# Looping mode; the schedule starts at the designated time, and every loop_interval seconds after
+# for the designated number of repeats
+uint8 MODE_LOOP=1
+
+# Single-shot execution, but does NOT get added to the persistent storage
+# Equivalent to MODE_ONCE, but for one-off, throw-away schedules (e.g. "Run X in 5 minutes")
+uint8 MODE_TRANSIENT=2
+
+# The human-readable name for this schedule
+# Should be unique, but there's no hard requirement for it to be so
+string name
+
+# The unique ID of this schedule
+# A string of the form "12345678-90ab-cdef-1234-567890abcdef"
+string uuid
+
+# The time that this mission starts every day
+clearpath_mission_scheduler_msgs/UtcTime start_time
+
+# Either MODE_ONCE or MODE_LOOP to indicate the execution mode
+uint8 mode
+
+# In MODE_LOOP, how many times do we repeat the missions?
+uint8 loop_repeats
+
+# In MODE_LOOP, how long do we wait between executions?
+duration loop_interval
+
+# The ordered list of Mission UUIDs to execute
+string[] mission_ids
+
+# The minimum battery charge needed before we execute the missions
+# Must be in the range 0-1
+float32 min_battery
+
+# If the missions take longer than this to execute, assume the schedule has failed and alert the user
+# Set to zero to disable the timeout
+duration timeout
+
+# Is this schedule enabled?
+# Only enabled schedules will execute
+bool enabled
+```
+
+#### clearpath_mission_scheduler_msgs/msg/StorageState.msg {#scheduler-state}
+
+```
+# Single-execution mode; the schedule starts at the designated time and runs once
+uint8 MODE_ONCE=0
+
+# Looping mode; the schedule starts at the designated time, and every loop_interval seconds after
+# for the designated number of repeats
+uint8 MODE_LOOP=1
+
+# Single-shot execution, but does NOT get added to the persistent storage
+# Equivalent to MODE_ONCE, but for one-off, throw-away schedules (e.g. "Run X in 5 minutes")
+uint8 MODE_TRANSIENT=2
+
+# The human-readable name for this schedule
+# Should be unique, but there's no hard requirement for it to be so
+string name
+
+# The unique ID of this schedule
+# A string of the form "12345678-90ab-cdef-1234-567890abcdef"
+string uuid
+
+# The time that this mission starts every day
+clearpath_mission_scheduler_msgs/UtcTime start_time
+
+# Either MODE_ONCE or MODE_LOOP to indicate the execution mode
+uint8 mode
+
+# In MODE_LOOP, how many times do we repeat the missions?
+uint8 loop_repeats
+
+# In MODE_LOOP, how long do we wait between executions?
+duration loop_interval
+
+# The ordered list of Mission UUIDs to execute
+string[] mission_ids
+
+# The minimum battery charge needed before we execute the missions
+# Must be in the range 0-1
+float32 min_battery
+
+# If the missions take longer than this to execute, assume the schedule has failed and alert the user
+# Set to zero to disable the timeout
+duration timeout
+
+# Is this schedule enabled?
+# Only enabled schedules will execute
+bool enabled
+```
+
+#### clearpath_mission_scheduler_msgs/msg/UtcTime.msg {#scheduler-time}
+
+```
+# Represents a moment in time on a 24-hour clock
+
+# The hour, 0-23
+uint8 hour
+
+# The minute, 0-59
+uint8 minute
+
+# The second, 0-59
+uint8 second
+
+# Milliseconds, 0-999 (not typically needed)
+uint16 millisecond
+```
+
#### clearpath_navigation_msgs/Mission.msg {#msg-navigation-mission}
```
@@ -420,148 +549,6 @@ bool[] lidar_watchdog_triggered
bool[] camera_watchdog_triggered
```
-#### cpr_mission_manager_msgs/msg/StorageState.msg {#storage-storagestate}
-
-```
-# All missions defined in the database
-cpr_navigation_msgs/Mission[] missions
-
-# All waypoints defined in the database
-cpr_navigation_msgs/Waypoint[] waypoints
-
-# All tasks defined in the database
-cpr_navigation_msgs/Task[] tasks
-```
-
-#### cpr_mission_scheduler_msgs/msg/NextSchedule.msg
-
-```
-# The ID of the next schedule to start
-# Empty if nothing is scheduled
-string uuid
-
-# The time until the schedule starts (rounded to the nearest second)
-duration time_to_start
-```
-
-#### cpr_mission_scheduler_msgs/msg/Schedule {#scheduler-schedule}
-
-```
-# Single-execution mode; the schedule starts at the designated time and runs once
-uint8 MODE_ONCE=0
-
-# Looping mode; the schedule starts at the designated time, and every loop_interval seconds after
-# for the designated number of repeats
-uint8 MODE_LOOP=1
-
-# Single-shot execution, but does NOT get added to the persistent storage
-# Equivalent to MODE_ONCE, but for one-off, throw-away schedules (e.g. "Run X in 5 minutes")
-uint8 MODE_TRANSIENT=2
-
-# The human-readable name for this schedule
-# Should be unique, but there's no hard requirement for it to be so
-string name
-
-# The unique ID of this schedule
-# A string of the form "12345678-90ab-cdef-1234-567890abcdef"
-string uuid
-
-# The time that this mission starts every day
-cpr_mission_scheduler_msgs/UtcTime start_time
-
-# Either MODE_ONCE or MODE_LOOP to indicate the execution mode
-uint8 mode
-
-# In MODE_LOOP, how many times do we repeat the missions?
-uint8 loop_repeats
-
-# In MODE_LOOP, how long do we wait between executions?
-duration loop_interval
-
-# The ordered list of Mission UUIDs to execute
-string[] mission_ids
-
-# The minimum battery charge needed before we execute the missions
-# Must be in the range 0-1
-float32 min_battery
-
-# If the missions take longer than this to execute, assume the schedule has failed and alert the user
-# Set to zero to disable the timeout
-duration timeout
-
-# Is this schedule enabled?
-# Only enabled schedules will execute
-bool enabled
-```
-
-#### cpr_mission_scheduler_msgs/msg/StorageState.msg {#scheduler-state}
-
-```
-# Single-execution mode; the schedule starts at the designated time and runs once
-uint8 MODE_ONCE=0
-
-# Looping mode; the schedule starts at the designated time, and every loop_interval seconds after
-# for the designated number of repeats
-uint8 MODE_LOOP=1
-
-# Single-shot execution, but does NOT get added to the persistent storage
-# Equivalent to MODE_ONCE, but for one-off, throw-away schedules (e.g. "Run X in 5 minutes")
-uint8 MODE_TRANSIENT=2
-
-# The human-readable name for this schedule
-# Should be unique, but there's no hard requirement for it to be so
-string name
-
-# The unique ID of this schedule
-# A string of the form "12345678-90ab-cdef-1234-567890abcdef"
-string uuid
-
-# The time that this mission starts every day
-cpr_mission_scheduler_msgs/UtcTime start_time
-
-# Either MODE_ONCE or MODE_LOOP to indicate the execution mode
-uint8 mode
-
-# In MODE_LOOP, how many times do we repeat the missions?
-uint8 loop_repeats
-
-# In MODE_LOOP, how long do we wait between executions?
-duration loop_interval
-
-# The ordered list of Mission UUIDs to execute
-string[] mission_ids
-
-# The minimum battery charge needed before we execute the missions
-# Must be in the range 0-1
-float32 min_battery
-
-# If the missions take longer than this to execute, assume the schedule has failed and alert the user
-# Set to zero to disable the timeout
-duration timeout
-
-# Is this schedule enabled?
-# Only enabled schedules will execute
-bool enabled
-```
-
-#### cpr_mission_scheduler_msgs/msg/UtcTime.msg {#scheduler-time}
-
-```
-# Represents a moment in time on a 24-hour clock
-
-# The hour, 0-23
-uint8 hour
-
-# The minute, 0-59
-uint8 minute
-
-# The second, 0-59
-uint8 second
-
-# Milliseconds, 0-999 (not typically needed)
-uint16 millisecond
-```
-
#### Standard ROS Messages {#std-ros-msgs}
- [actionlib_msgs/GoalID](http://docs.ros.org/en/noetic/api/actionlib_msgs/html/msg/GoalID.html)
@@ -572,442 +559,96 @@ uint16 millisecond
- [geometry_msgs/Twist](http://docs.ros.org/en/noetic/api/geometry_msgs/html/msg/Twist.html)
- [nav_msgs/OccupancyGrid](http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/OccupancyGrid.html)
- [nav_msgs/Odometry](http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/Odometry.html)
-- [nav_msgs/Path](http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/Path.html)
-- [sensor_msgs/Imu](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/Imu.html)
-- [sensor_msgs/LaserScan](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/LaserScan.html)
-- [sensor_msgs/NavSatFix](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/NavSatFix.html)
-- [sensor_msgs/PointCloud2](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/PointCloud2.html)
-- [std_msgs/Bool](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/Bool.html)
-- [std_msgs/Empty](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/Empty.html)
-- [std_msgs/String](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/String.html)
-- [tf2_msgs/TFMessage](http://docs.ros.org/en/noetic/api/tf2_msgs/html/msg/TFMessage.html)
-- [wireless_msgs/Connection](http://docs.ros.org/en/noetic/api/wireless_msgs/html/msg/Connection.html)
-
-------------------------------------------------------------------------
-
-### Service Definitions
-
-#### clearpath_control_msgs/srv/SetControlMode.srv {#srv-set-control-mode}
-
-```
-# Service definition to set the control mode
-
-clearpath_control_msgs/ControlMode mode
----
-```
-
-#### clearpath_dock_msgs/srv/AddDock.srv {#srv-add-dock}
-
-```
-# A dock information message that will be added to the docks list
-clearpath_dock_msgs/DockInfo dock
----
-# True if the location was updated/added successfully, otherwise False
-bool success
-```
-
-#### clearpath_dock_msgs/srv/RemoveDock.srv {#srv-remove-dock}
-
-```
-# A dock information message that will be added to the docks list
-string uuid
-string name
----
-# True if the location was updated/added successfully, otherwise False
-bool success
-```
-
-#### clearpath_dock_msgs/srv/SetDockLocationById.srv {#srv-set-dock-location-by-id}
-
-```
-# The UUID of the dock we're setting a location for
-# If empty, a new dock is to be added with the location
-string uuid
----
-# True if the location was updated/added successfully, otherwise False
-bool success
-```
-
-#### clearpath_dock_msgs/srv/SetDockLocationByName.srv {#srv-set-dock-location-by-name}
-
-```
-# The UUID of the dock we're setting a location for
-# If empty, a new dock is to be added with the location
-string name
----
-# True if the location was updated/added successfully, otherwise False
-bool success
-```
-
-#### clearpath_localization_msgs/srv/SetDatum.srv {#srv-set-datum}
-
-```
-# Service definition to set the datum with a latitude (lat) and longitude (lon)
-
-float32 lat
-float32 lon
----
-bool success
-```
-
-#### clearpath_localization_msgs/srv/ResetLocalization.srv {#srv-reset-localization}
-
-```
-# Service definition to reset the localization
-
-bool require_gnss
-uint32 gnss_samples
----
-bool success
-```
-
-
-#### clearpath_mission_manager_msgs/srv/AddRemoveById.srv {#storage-addremovebyid}
-
-```
-# The UUID of the object we're inserting/removing
-# When removing, all instances with this UUID are deleted from the parent
-string uuid
-
-# The UUID of the parent object
-string parent_uuid
-
-# The zero-based index to insert the object into
-# Ignored when removing
-int32 position
----
-# True if the object was added/removed successfully, otherwise False
-bool ok
-```
-
-#### clearpath_mission_manager_msgs/srv/CloneMission.srv {#storage-clonemission}
-```
-# The desired name for the new mission
-string name
-
-# The additional configuration options
-# see clearpath_navigation_msgs/msg/Mission for details
-string onav_config
-
-# The ordered list of Waypoint UUIDs to include in this mission
-string[] waypoint_ids
----
-# The resulting Mission, with an auto-generated UUID is returned
-clearpath_navigation_msgs/Mission result
-```
-
-#### clearpath_mission_manager_msgs/srv/CreateMission.srv {#storage-createmission}
-
-```
-# The desired name for the new mission
-string name
-
-# The additional configuration options
-# see clearpath_mission_manager_msgs/msg/Mission for details
-string onav_config
-
-# The ordered list of Waypoint UUIDs to include in this mission
-string[] waypoint_ids
----
-# The resulting Mission, with an auto-generated UUID is returned
-clearpath_navigation_msgs/Mission result
-```
-
-#### clearpath_mission_manager_msgs/srv/CreateTask.srv {#storage-createtask}
-
-```
-# The desired name for the Task
-string name
-
-# The ROS Action to invoke to execute the task
-string service_call
-
-# The version of the task
-string version
-
-# The numerical arguments to pass to the service_call
-float64[] floats
-
-# The string arguments to pass to the service_call
-string[] strings
-
-# Optional list of Waypoint UUIDs to assign this task to automatically
-# The new task will be appended to the end of the existing Waypoints
-string[] assign_to
----
-# The resulting Task with an auto-generated UUID is returned
-clearpath_navigation_msgs/Task result
-```
-
-#### clearpath_mission_manager_msgs/srv/CreateWaypoint.srv {#storage-createwaypoint}
-
-```
-# The desired name for the Waypoint
-string name
-
-# The latitude for the Waypoint in degrees
-float64 latitude
-
-# The longitude for the Waypoint in degrees
-float64 longitude
-
-# The compass heading in degrees for the Waypoint
-float64 heading
-
-# The position tolerance for the Waypoint in meters
-float64 position_tolerance
-
-# The orientation tolerance for the Waypoint in degrees
-float64 yaw_tolerance
-
-# Optional ordered list of Task UUIDs to execute at this Waypoint
-string[] task_ids
-
-# Optional list of Mission UUIDs to assign the new Waypoint to
-# The new Waypoint is appended to the end of the existing Missions
-string[] assign_to
----
-# The resulting Waypoint with an auto-generated UUID is returned
-clearpath_navigation_msgs/Waypoint result
-```
-
-#### clearpath_mission_manager_msgs/srv/DeleteById.srv {#storage-deletebyid}
-
-```
-# The UUID of the object we want to delete
-string uuid
----
-# True if the item was successfully deleted, otherwise False
-bool ok
-```
-
-#### clearpath_mission_manager_msgs/srv/DeleteEverything.srv {#storage-deleteeverything}
-
-```
-# Used to permanently delete everything from the database.
-# Use this service at your own risk
-
-# This must be set to true to confirm you really want to delete everything
-bool yes_i_am_absolutely_sure_i_want_to_do_this
----
-# True if the database was cleared, otherwise False
-bool ok
-```
-
-#### clearpath_mission_manager_msgs/srv/ExportData.srv {#storage-exportdata}
-
-```
----
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
-# This can be written to a file or used with the ImportData.srv
-# to back-up/restore the database contents
-string data
-```
-
-#### clearpath_mission_manager_msgs/srv/GetAllMissions.srv {#storage-getallmissions}
-
-```
----
-# An array of all Missions defined in the database
-clearpath_navigation_msgs/Mission[] missions
-```
-
-#### clearpath_mission_manager_msgs/srv/GetAllTasks.srv {#storage-getalltasks}
-
-```
----
-# The array of all Tasks defined in the database
-clearpath_navigation_msgs/Task[] tasks
-```
-
-#### clearpath_mission_manager_msgs/srv/GetAllWaypoints.srv {#storage-getallwaypoints}
-
-```
----
-# The array of all Waypoints defined in the database
-clearpath_navigation_msgs/Waypoint[] waypoints
-```
-
-#### clearpath_mission_manager_msgs/srv/GetEverything.srv {#storage-geteverything}
-
-```
----
-# All Missions, Waypoints, and Tasks defined in the database
-clearpath_mission_manager_msgs/StorageState state
-```
-
-#### clearpath_mission_manager_msgs/srv/GetMission.srv {#storage-getmission}
-
-```
-# The UUID of the Mission we want to retrieve
-string uuid
----
-# The Mission with the given ID, or null if no Mission with that ID exists
-clearpath_navigation_msgs/Mission mission
-```
-
-#### clearpath_mission_manager_msgs/srv/GetTask.srv {#storage-gettask}
-
-```
-# The UUID of the Task we want to retrieve
-string uuid
----
-# The Task with the given ID, or null if no Task with that ID exists
-clearpath_navigation_msgs/Task task
-```
-
-#### clearpath_mission_manager_msgs/srv/GetWaypoint.srv {#storage-getwaypoint}
-
-```
-# The UUID of the Waypoint we want to retrieve
-string uuid
----
-# The Waypoint with the given ID, or null if no Waypoint with that ID exists
-clearpath_navigation_msgs/Waypoint waypoint
-```
+- [nav_msgs/Path](http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/Path.html)
+- [sensor_msgs/Imu](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/Imu.html)
+- [sensor_msgs/LaserScan](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/LaserScan.html)
+- [sensor_msgs/NavSatFix](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/NavSatFix.html)
+- [sensor_msgs/PointCloud2](http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/PointCloud2.html)
+- [std_msgs/Bool](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/Bool.html)
+- [std_msgs/Empty](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/Empty.html)
+- [std_msgs/String](http://docs.ros.org/en/noetic/api/std_msgs/html/msg/String.html)
+- [tf2_msgs/TFMessage](http://docs.ros.org/en/noetic/api/tf2_msgs/html/msg/TFMessage.html)
+- [wireless_msgs/Connection](http://docs.ros.org/en/noetic/api/wireless_msgs/html/msg/Connection.html)
-#### clearpath_mission_manager_msgs/srv/ImportData.srv {#storage-importdata}
+------------------------------------------------------------------------
-```
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
-# This is the same as the data output by the ExportData service, and is intended
-# to be used to restore the database to a previous state
-string data
----
-# The state of the database after importing the data
-clearpath_mission_manager_msgs/StorageState state
-```
+### Service Definitions
-#### clearpath_mission_manager_msgs/srv/UpdateMission.srv {#storage-updatemission}
+#### clearpath_control_msgs/srv/SetControlMode.srv {#srv-set-control-mode}
```
-# The UUID of the mission we want to edit
-string uuid
-
-# The human-readable name for the Mission
-string name
-
-# The configuration parameters for the Mission
-string onav_config
+# Service definition to set the control mode
-# The ordered list of Waypoint UUIDs to include in the Mission
-string[] waypoint_ids
+clearpath_control_msgs/ControlMode mode
---
-# The edited Mission, or null if no mission with the given ID exists
-clearpath_navigation_msgs/Mission result
```
-#### clearpath_mission_manager_msgs/srv/UpdateTask.srv {#storage-updatetask}
+#### clearpath_dock_msgs/srv/AddDock.srv {#srv-add-dock}
```
-# The UUID of the Task to edit
-string uuid
-
-# The human-readable name for the Task
-string name
-
-# The ROS Action that the Task executes
-string service_call
-
-# The version of the Task
-string version
-
-# The numerical data to pass to the service_call
-float64[] floats
-
-# The string data to pass to the service_call
-string[] strings
+# A dock information message that will be added to the docks list
+clearpath_dock_msgs/DockInfo dock
---
-# The edited Task, or null if no Task with the given ID exists
-clearpath_navigation_msgs/Task result
+# True if the location was updated/added successfully, otherwise False
+bool success
```
-#### clearpath_mission_manager_msgs/srv/UpdateWaypoint.srv {#storage-updatewaypoint}
+#### clearpath_dock_msgs/srv/RemoveDock.srv {#srv-remove-dock}
```
-# The UUID of the Waypoint to edit
+# A dock information message that will remove a dock from the docks list
string uuid
-
-# The human-readable name for the Waypoint
string name
-
-# The latitude of the Waypoint in degrees
-float64 latitude
-
-# The longitude of the Waypoint in degrees
-float64 longitude
-
-# The compass heading of the Waypoint in degrees
-float64 heading
-
-# The Waypoint's position tolerance in meters
-float64 position_tolerance
-
-# The Waypoint's orientation tolerance in degrees
-float64 yaw_tolerance
-
-# The ordered list of Task UUIDs to execute at this Waypoint
-string[] task_ids
---
-# The edited Waypoint, or null if no Waypoint with the given ID exists
-clearpath_navigation_msgs/Waypoint result
+# True if the dock was removed successfully, otherwise False
+bool success
```
-#### clearpath_navigation_msgs/srv/SetDelayCompensation.srv {#srv-set-delay-compensation}
+#### clearpath_dock_msgs/srv/SetDockLocationById.srv {#srv-set-dock-location-by-id}
```
-# Service definition to enable/disable the delay compensation feature. If enabling, the delay to compensate for must be specified in the request.
-
-bool enable_delay_compensation
-uint16 delay
+# The UUID of the dock we're setting a location for
+# If empty, a new dock is to be added with the location
+string uuid
---
+# True if the location was updated/added successfully, otherwise False
bool success
-string message
```
-#### clearpath_navigation_msgs/srv/SetPathSmoother.srv {#srv-set-path-smoother}
+#### clearpath_dock_msgs/srv/SetDockLocationByName.srv {#srv-set-dock-location-by-name}
```
-# Service definition to enable/disable the path smoothing feature. If enabling, minimum turning radius must be specified in the request.
-
-bool enable_path_smoother
-float32 turn_radius
-float32 step_size
+# The UUID of the dock we're setting a location for
+# If empty, a new dock is to be added with the location
+string name
---
+# True if the location was updated/added successfully, otherwise False
bool success
-string message
```
-#### clearpath_navigation_msgs/srv/SetPathShifter.srv {#srv-set-path-shifter}
+#### clearpath_localization_msgs/srv/SetDatum.srv {#srv-set-datum}
```
-# Service definition to enable/disable the path smoothing feature. If enabling, minimum turning radius must be specified in the request.
+# Service definition to set the datum with a latitude (lat) and longitude (lon)
-bool enable_path_shifter
-float32 path_shift_offset
-float32 path_shift_time
+float32 lat
+float32 lon
---
bool success
-string message
```
-#### clearpath_navigation_msgs/srv/SetStopDistance.srv {#srv-set-stop-distance}
+#### clearpath_localization_msgs/srv/ResetLocalization.srv {#srv-reset-localization}
```
-# Service definition to enable/disable the stop distance. If enabling, the stop distance must be specified in the request.
+# Service definition to reset the localization
-bool enable_stop_distance
-float32 stop_distance
+bool require_gnss
+uint32 gnss_samples
---
bool success
-string message
```
-#### cpr_mission_manager_msgs/srv/AddRemoveById.srv {#storage-addremovebyid}
+#### clearpath_mission_manager_msgs/srv/AddRemoveById.srv {#storage-addremovebyid}
```
# The UUID of the object we're inserting/removing
@@ -1025,7 +666,7 @@ int32 position
bool ok
```
-#### cpr_mission_manager_msgs/srv/CloneMission.srv {#storage-clonemission}
+#### clearpath_mission_manager_msgs/srv/CloneMission.srv {#storage-clonemission}
```
# The UUID of the mission to clone
string uuid
@@ -1038,7 +679,7 @@ string new_name
bool reverse
---
# The Mission with the given ID, or null if no Mission with that ID exists
-cpr_navigation_msgs/Mission mission
+clearpath_navigation_msgs/Mission mission
```
:::note
@@ -1047,24 +688,24 @@ The `reverse` parameter was added in 0.9.0
:::
-#### cpr_mission_manager_msgs/srv/CreateMission.srv {#storage-createmission}
+#### clearpath_mission_manager_msgs/srv/CreateMission.srv {#storage-createmission}
```
# The desired name for the new mission
string name
# The additional configuration options
-# see cpr_mission_manager_msgs/msg/Mission for details
+# see clearpath_mission_manager_msgs/msg/Mission for details
string onav_config
# The ordered list of Waypoint UUIDs to include in this mission
string[] waypoint_ids
---
# The resulting Mission, with an auto-generated UUID is returned
-cpr_navigation_msgs/Mission result
+clearpath_navigation_msgs/Mission result
```
-#### cpr_mission_manager_msgs/srv/CreateTask.srv {#storage-createtask}
+#### clearpath_mission_manager_msgs/srv/CreateTask.srv {#storage-createtask}
```
# The desired name for the Task
@@ -1087,10 +728,10 @@ string[] strings
string[] assign_to
---
# The resulting Task with an auto-generated UUID is returned
-cpr_navigation_msgs/Task result
+clearpath_navigation_msgs/Task result
```
-#### cpr_mission_manager_msgs/srv/CreateWaypoint.srv {#storage-createwaypoint}
+#### clearpath_mission_manager_msgs/srv/CreateWaypoint.srv {#storage-createwaypoint}
```
# The desired name for the Waypoint
@@ -1119,10 +760,10 @@ string[] task_ids
string[] assign_to
---
# The resulting Waypoint with an auto-generated UUID is returned
-cpr_navigation_msgs/Waypoint result
+clearpath_navigation_msgs/Waypoint result
```
-#### cpr_mission_manager_msgs/srv/DeleteById.srv {#storage-deletebyid}
+#### clearpath_mission_manager_msgs/srv/DeleteById.srv {#storage-deletebyid}
```
# The UUID of the object we want to delete
@@ -1132,7 +773,7 @@ string uuid
bool ok
```
-#### cpr_mission_manager_msgs/srv/DeleteEverything.srv {#storage-deleteeverything}
+#### clearpath_mission_manager_msgs/srv/DeleteEverything.srv {#storage-deleteeverything}
```
# Used to permanently delete everything from the database.
@@ -1145,95 +786,111 @@ bool yes_i_am_absolutely_sure_i_want_to_do_this
bool ok
```
-#### cpr_mission_manager_msgs/srv/ExportData.srv {#storage-exportdata}
+#### clearpth_mission_manager_msgs/srv/DeleteMultiple.srv {#storage-deletemultiple}
+
+```
+# A list of UUIDs of items we want to delete
+string[] uuids
+---
+# A list of UUIDs that we were asked to delete, but failed to
+string[] failed_uuids
+```
+
+#### clearpath_mission_manager_msgs/srv/ExportData.srv {#storage-exportdata}
```
---
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
+# A JSON string representing the database contents.
# This can be written to a file or used with the ImportData.srv
# to back-up/restore the database contents
string data
```
-#### cpr_mission_manager_msgs/srv/GetAllMissions.srv {#storage-getallmissions}
+#### clearpath_mission_manager_msgs/srv/GetAllMissions.srv {#storage-getallmissions}
```
---
# An array of all Missions defined in the database
-cpr_navigation_msgs/Mission[] missions
+clearpath_navigation_msgs/Mission[] missions
```
-#### cpr_mission_manager_msgs/srv/GetAllTasks.srv {#storage-getalltasks}
+#### clearpath_mission_manager_msgs/srv/GetAllTasks.srv {#storage-getalltasks}
```
---
# The array of all Tasks defined in the database
-cpr_navigation_msgs/Task[] tasks
+clearpath_navigation_msgs/Task[] tasks
```
-#### cpr_mission_manager_msgs/srv/GetAllWaypoints.srv {#storage-getallwaypoints}
+#### clearpath_mission_manager_msgs/srv/GetAllWaypoints.srv {#storage-getallwaypoints}
```
---
# The array of all Waypoints defined in the database
-cpr_navigation_msgs/Waypoint[] waypoints
+clearpath_navigation_msgs/Waypoint[] waypoints
```
-#### cpr_mission_manager_msgs/srv/GetEverything.srv {#storage-geteverything}
+#### clearpath_mission_manager_msgs/srv/GetEverything.srv {#storage-geteverything}
```
---
# All Missions, Waypoints, and Tasks defined in the database
-cpr_mission_manager_msgs/StorageState state
+clearpath_mission_manager_msgs/StorageState state
```
-#### cpr_mission_manager_msgs/srv/GetMission.srv {#storage-getmission}
+#### clearpath_mission_manager_msgs/srv/GetMission.srv {#storage-getmission}
```
# The UUID of the Mission we want to retrieve
string uuid
---
# The Mission with the given ID, or null if no Mission with that ID exists
-cpr_navigation_msgs/Mission mission
+clearpath_navigation_msgs/Mission mission
```
-#### cpr_mission_manager_msgs/srv/GetTask.srv {#storage-gettask}
+#### clearpath_mission_manager_msgs/srv/GetTask.srv {#storage-gettask}
```
# The UUID of the Task we want to retrieve
string uuid
---
# The Task with the given ID, or null if no Task with that ID exists
-cpr_navigation_msgs/Task task
+clearpath_navigation_msgs/Task task
```
-#### cpr_mission_manager_msgs/srv/GetWaypoint.srv {#storage-getwaypoint}
+#### clearpath_mission_manager_msgs/srv/GetWaypoint.srv {#storage-getwaypoint}
```
# The UUID of the Waypoint we want to retrieve
string uuid
---
# The Waypoint with the given ID, or null if no Waypoint with that ID exists
-cpr_navigation_msgs/Waypoint waypoint
+clearpath_navigation_msgs/Waypoint waypoint
```
-#### cpr_mission_manager_msgs/srv/ImportData.srv {#storage-importdata}
+#### clearpath_mission_manager_msgs/srv/ImportData.srv {#storage-importdata}
```
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
+# A JSON string representing the database contents.
# This is the same as the data output by the ExportData service, and is intended
# to be used to restore the database to a previous state
string data
---
# The state of the database after importing the data
-cpr_mission_manager_msgs/StorageState state
+clearpath_mission_manager_msgs/StorageState state
+```
+
+#### clearpath_mission_manager_msgs/srv/ImportMission.srv {#storage-importmission}
+
+```
+# The Mission to import. All UUIDs will be re-generated
+clearpath_navigation_msgs/Mission mission
+---
+# The generated mission with new UUIDs
+clearpath_navigation_msgs/Mission mission
```
-#### cpr_mission_manager_msgs/srv/UpdateMission.srv {#storage-updatemission}
+#### clearpath_mission_manager_msgs/srv/UpdateMission.srv {#storage-updatemission}
```
# The UUID of the mission we want to edit
@@ -1249,10 +906,10 @@ string onav_config
string[] waypoint_ids
---
# The edited Mission, or null if no mission with the given ID exists
-cpr_navigation_msgs/Mission result
+clearpath_navigation_msgs/Mission result
```
-#### cpr_mission_manager_msgs/srv/UpdateTask.srv {#storage-updatetask}
+#### clearpath_mission_manager_msgs/srv/UpdateTask.srv {#storage-updatetask}
```
# The UUID of the Task to edit
@@ -1274,10 +931,10 @@ float64[] floats
string[] strings
---
# The edited Task, or null if no Task with the given ID exists
-cpr_navigation_msgs/Task result
+clearpath_navigation_msgs/Task result
```
-#### cpr_mission_manager_msgs/srv/UpdateWaypoint.srv {#storage-updatewaypoint}
+#### clearpath_mission_manager_msgs/srv/UpdateWaypoint.srv {#storage-updatewaypoint}
```
# The UUID of the Waypoint to edit
@@ -1305,10 +962,10 @@ float64 yaw_tolerance
string[] task_ids
---
# The edited Waypoint, or null if no Waypoint with the given ID exists
-cpr_navigation_msgs/Waypoint result
+clearpath_navigation_msgs/Waypoint result
```
-#### cpr_mission_scheduler_msgs/srv/CloneSchedule.srv {#scheduler-cloneschedule}
+#### clearpath_mission_scheduler_msgs/srv/CloneSchedule.srv {#scheduler-cloneschedule}
```
# The UUID of the schedule to clone
@@ -1319,10 +976,10 @@ string new_name
---
# The cloned schedule
# This should be identical to the original, but with a new name and new UUID
-cpr_mission_scheduler_msgs/Schedule schedule
+clearpath_mission_scheduler_msgs/Schedule schedule
```
-#### cpr_mission_scheduler_msgs/srv/CreateSchedule.srv {#scheduler-createschedule}
+#### clearpath_mission_scheduler_msgs/srv/CreateSchedule.srv {#scheduler-createschedule}
```
# The human-readable name for this schedule
@@ -1330,7 +987,7 @@ cpr_mission_scheduler_msgs/Schedule schedule
string name
# The time that this mission starts every day
-cpr_mission_scheduler_msgs/UtcTime start_time
+clearpath_mission_scheduler_msgs/UtcTime start_time
# Either Schedule.MODE_ONCE, Schedule.MODE_LOOP, OR Schedule.MODE_TRANSIENT to indicate the execution mode
uint8 mode
@@ -1359,10 +1016,10 @@ bool enabled
---
# The created mission, as-saved on disk
-cpr_mission_scheduler_msgs/Schedule result
+clearpath_mission_scheduler_msgs/Schedule result
```
-#### cpr_mission_scheduler_msgs/srv/EnableSchedule.srv {#scheduler-enableschedule}
+#### clearpath_mission_scheduler_msgs/srv/EnableSchedule.srv {#scheduler-enableschedule}
```
# The ID of the schedule to enable/disable
@@ -1378,26 +1035,24 @@ bool enable
bool ok
```
-#### cpr_mission_scheduler_msgs/srv/ExportData.srv {#scheduler-exportdata}
+#### clearpath_mission_scheduler_msgs/srv/ExportData.srv {#scheduler-exportdata}
```
---
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
+# A JSON string representing the database contents.
# This can be written to a file or used with the ImportData.srv
# to back-up/restore the database contents
string data
```
-#### cpr_mission_scheduler_msgs/srv/GetAllSchedules.srv {#scheduler-getallschedules}
+#### clearpath_mission_scheduler_msgs/srv/GetAllSchedules.srv {#scheduler-getallschedules}
```
---
-cpr_mission_scheduler_msgs/Schedule[] schedules
+clearpath_mission_scheduler_msgs/Schedule[] schedules
```
-#### cpr_mission_scheduler_msgs/srv/GetNextSchedule.srv {#scheduler-getnextschedule}
+#### clearpath_mission_scheduler_msgs/srv/GetNextSchedule.srv {#scheduler-getnextschedule}
```
---
@@ -1409,29 +1064,27 @@ string uuid
duration time_to_start
```
-#### cpr_mission_scheduler_msgs/srv/GetSchedule.srv {#scheduler-getschedule}
+#### clearpath_mission_scheduler_msgs/srv/GetSchedule.srv {#scheduler-getschedule}
```
string uuid
---
-cpr_mission_scheduler_msgs/Schedule schedule
+clearpath_mission_scheduler_msgs/Schedule schedule
```
-#### cpr_mission_scheduler_msgs/srv/ImportData.srv {#scheduler-importdata}
+#### clearpath_mission_scheduler_msgs/srv/ImportData.srv {#scheduler-importdata}
```
-# A base-64 encoded string representing a compressed version of
-# the database contents.
-# The data itself is a gzipped JSON string representing the database contents
+# A JSON string representing the database contents.
# This is the same as the data output by the ExportData service, and is intended
# to be used to restore the database to a previous state
string data
---
# The state of the database after importing the data
-cpr_mission_scheduler_msgs/StorageState state
+clearpath_mission_scheduler_msgs/StorageState state
```
-#### cpr_mission_scheduler_msgs/srv/UpdateSchedule.srv {scheduler-updateschedule}
+#### clearpath_mission_scheduler_msgs/srv/UpdateSchedule.srv {scheduler-updateschedule}
```
# The ID of the mission to edit
@@ -1442,7 +1095,7 @@ string uuid
string name
# The time that this mission starts every day
-cpr_mission_scheduler_msgs/UtcTime start_time
+clearpath_mission_scheduler_msgs/UtcTime start_time
# Either Schedule.MODE_ONCE, Schedule.MODE_LOOP, OR Schedule.MODE_TRANSIENT to indicate the execution mode
uint8 mode
@@ -1471,7 +1124,44 @@ bool enabled
---
# The modified mission, as-saved on disk
-cpr_mission_scheduler_msgs/Schedule result
+clearpath_mission_scheduler_msgs/Schedule result
+```
+
+#### clearpath_navigation_msgs/srv/SetDelayCompensation.srv {#srv-set-delay-compensation}
+
+```
+# Service definition to enable/disable the delay compensation feature. If enabling, the delay to compensate for must be specified in the request.
+
+bool enable_delay_compensation
+uint16 delay # units: milliseconds
+---
+bool success
+string message
+```
+
+#### clearpath_navigation_msgs/srv/SetPathSmoother.srv {#srv-set-path-smoother}
+
+```
+# Service definition to enable/disable the path smoothing feature. If enabling, minimum turning radius must be specified in the request.
+
+bool enable_path_smoother
+float32 turn_radius # units: meters
+float32 step_size
+---
+bool success
+string message
+```
+
+#### clearpath_navigation_msgs/srv/SetStopDistance.srv {#srv-set-stop-distance}
+
+```
+# Service definition to enable/disable the stop distance. If enabling, the stop distance must be specified in the request.
+
+bool enable_stop_distance
+float32 stop_distance # units: meters
+---
+bool success
+string message
```
#### Standard ROS Services
@@ -1537,6 +1227,29 @@ bool success
float32 percent_complete
```
+
+#### clearpath_mission_scheduler_msgs/action/RunScheduleByUuid.action {#scheduler-runschedulebyuuid}
+
+```
+# Action definition for executing a schedule on-demand
+# Potentially only useful for debugging
+
+# The UUID of the schedule to execute
+string uuid
+
+# Wait this long before starting the schedule (ros:Duration msg, so the units are secs/nsecs)
+duration delay
+---
+# Did the schedule terminate successfully?
+bool success
+---
+# The ID of the mission we're executing right now
+string current_mission_uuid
+
+# One of "waiting" or "executing" indicating what the schedule is doing
+string state
+```
+
#### clearpath_navigation_msgs/action/ExecuteMissionByUuid.action {#action-execute-mission-by-uuid}
```
@@ -1581,44 +1294,3 @@ bool success
# feedback
string state
```
-
-#### clearpath_dock_msgs/action/Dock.action {#action-dock}
-
-```
-# Action definition for sending a Clearpath UGV to its charging dock.
-
-# goal
-uint8 DOCK = 0
-uint8 UNDOCK = 1
-float32 type
-float32 enable_predock
----
-# result
-bool success
----
-# feedback
-string state
-float64 dist_to_dock # (IN DEVELOPMENT)
-```
-
-#### cpr_mission_scheduler_msgs/action/RunScheduleByUuid.action {#scheduler-runschedulebyuuid}
-
-```
-# Action definition for executing a schedule on-demand
-# Potentially only useful for debugging
-
-# The UUID of the schedule to execute
-string uuid
-
-# Wait this long before starting the schedule
-duration delay
----
-# Did the schedule terminate successfully?
-bool success
----
-# The ID of the mission we're executing right now
-string current_mission_uuid
-
-# One of "waiting" or "executing" indicating what the schedule is doing
-string state
-```
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 4cc414c0..b60ca9c5 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
@@ -112,6 +112,13 @@ Use with extreme caution; this procedure cannot be undone.
**Description:** Delete the Mission with the given ID. Waypoints that are included in this mission are not
deleted, as they may be referenced by other Missions.
+#### mission_manager/delete_missions
+
+**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteMultiple](definitions.mdx#storage-deletemultiple)
+
+**Description:** Delete the missions with the given IDs. Waypoints that are part of these missions are not deleted,
+as they may be referenced by other Missions.
+
#### mission_manager/delete_orphan_objects
**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteEverything](definitions.mdx#storage-deleteeverything)
@@ -132,6 +139,12 @@ Use with caution; deleted items cannot be recovered.
**Description:** Delete the Task with the given ID. Any Waypoints that reference the deleted Task will be modified
to omit this Task once it is deleted.
+#### mission_manager/delete_tasks
+
+**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteMultiple](definitions.mdx#storage-deletemultiple)
+
+**Description:** Delete the tasks with the given IDs.
+
#### mission_manager/delete_waypoint
**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteById](definitions.mdx#storage-deletebyid)
@@ -140,15 +153,23 @@ to omit this Task once it is deleted.
deleted, as they may be referenced by other Waypoints. Any Missions that reference the deleted Waypoint will be
modified to omit this Waypoint once it is deleted.
+#### mission_manager/delete_waypoints
+
+**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteMultiple](definitions.mdx#storage-deletemultiple)
+
+**Description:** Delete the Waypoints with the given IDs. Tasks that are part of these Waypoints are not deleted,
+as they may be referenced by other Waypoints.
+
#### mission_manager/export
**Service Type:** [clearpath_mission_manager_msgs/srv/ExportData](definitions.mdx#storage-exportdata)
-**Description:** Export the database so its contents can be restored later using the `mission_manager/import` service.
+**Description:** Export the database so its contents can be restored later using the `mission_manager/restore` service
+or merged with other data using the `mission_manager/import` service.
:::note
-The data returned in a base64 encoded, gzipped JSON string representing the underlying storage file's contents.
+The data returned in a JSON string representing the underlying storage file's contents.
:::
@@ -205,17 +226,25 @@ should subscribe to the `mission_manager/state` topic.
**Service Type:** [clearpath_mission_manager_msgs/srv/ImportData](definitions.mdx#storage-importdata)
-**Description:** Overwite the database contents with data generated by the `mission_manager/export` service.
+**Description:** Add existing Missions, Tasks, and Waypoints to the database.
:::note
-All existing Missions, Tasks and Waypoints are deleted permanently and the entire database contents are replaced
-with the imported data.
+All imported Missions, Tasks, and Waypoints are added to the existing database. Items whose UUIDs already exist will
+be skipped & the existing copies re-used. This allows you to copy all mission objects from one robot to another.
-The data itself is a base64 encoded JSON string representing the underlying on-disk storage.
+To delete all data and restore a backup, instead of merging with existing data, use the `/mission_manager/restore`
+service instead.
:::
+#### mission_manager/import_mission
+
+**Service Type:** [clearpath_mission_manager_msgs/srv/ImportMission](definitions.mdx#storage-importmission)
+
+**Description:** Add existing Mission to the database. All UUIDs will be regenerated.
+
+
#### mission_manager/remove_task_from_waypoint
**Service Type:** [clearpath_mission_manager_msgs/srv/AddRemoveById](definitions.mdx#storage-addremovebyid)
@@ -228,6 +257,23 @@ The data itself is a base64 encoded JSON string representing the underlying on-d
**Description:** Remove a Waypoint from a Mission. All instances of the Waypoint are removed from the given Mission.
+#### mission_manager/restore
+
+**Service Type:** [clearpath_mission_manager_msgs/srv/ImportData](definitions.mdx#storage-importdata)
+
+**Description:** Overwite the database contents with data generated by the `mission_manager/export` service. This is
+intended to be used to restore a backup of the missions and roll the database back to an earlier state.
+
+:::note
+
+All existing Missions, Tasks and Waypoints are deleted permanently and the entire database contents are replaced
+with the imported data.
+
+To merge the data with the existing database, without deleting existing data, use the `/mission_manager/import`
+service instead.
+
+:::
+
#### mission_manager/update_mission
**Service Type:** [clearpath_mission_manager_msgs/srv/UpdateMission](definitions.mdx#storage-updatemission)
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 e77991e4..80a30da1 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
@@ -38,7 +38,7 @@ nearest minute when displaying the countdown information to the user in any sort
### mission_scheduler/next_schedule
-**Message Type:** [cpr_mission_scheduler_msgs/msg/NextSchedule](definitions.mdx#scheduler-nextschedule)
+**Message Type:** [clearpath_mission_scheduler_msgs/msg/NextSchedule](definitions.mdx#scheduler-nextschedule)
**Description:** Publishes the UUID and duration to the next scheduled mission. If no missions are scheduled the UUID
will be blank.
@@ -47,7 +47,7 @@ will be blank.
### mission_scheduler/state
-**Message Type:** [cpr_mission_scheduler_msgs/msg/StorageState](definitions.mdx#scheduler-state)
+**Message Type:** [clearpath_mission_scheduler_msgs/msg/StorageState](definitions.mdx#scheduler-state)
**Description:** Publishes the current state of the database. Anything that needs to display the current set of
schedules should subscribe to this topic
@@ -58,25 +58,25 @@ schedules should subscribe to this topic
### mission_scheduler/add_mission
-**Service Type:** [cpr_mission_manager_msgs/srv/AddRemoveById](definitions.mdx#storage-addremovebyid)
+**Service Type:** [clearpath_mission_manager_msgs/srv/AddRemoveById](definitions.mdx#storage-addremovebyid)
**Description:** Add a mission to an existing schedule.
### mission_scheduler/clone_schedule
-**Service Type:** [cpr_mission_scheduler_msgs/srv/CloneSchedule](definitions.mdx#scheduler-cloneschedule)
+**Service Type:** [clearpath_mission_scheduler_msgs/srv/CloneSchedule](definitions.mdx#scheduler-cloneschedule)
**Description:** Perform a deep-copy of an existing schedule
### mission_scheduler/create_schedule
-**Service Type:** [cpr_mission_scheduler_msgs/srv/CreateSchedule](definitions.mdx#scheduler-createschedule)
+**Service Type:** [clearpath_mission_scheduler_msgs/srv/CreateSchedule](definitions.mdx#scheduler-createschedule)
**Description:** Create a new schedule
### mission_scheduler/delete_all_schedules
-**Service Type:** [cpr_mission_manager_msgs/srv/DeleteEverything](definitions.mdx#storage-deleteeverything)
+**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteEverything](definitions.mdx#storage-deleteeverything)
**Description:** Delete all schedules.
@@ -88,7 +88,7 @@ This action is permanent and cannot be undone. Use with caution.
### mission_scheduler/delete_schedule
-**Service Type:** [cpr_mission_manager_msgs/srv/DeleteById](definitions.mdx#storage-deletebyid)
+**Service Type:** [clearpath_mission_manager_msgs/srv/DeleteById](definitions.mdx#storage-deletebyid)
**Description:** Delete a single schedule.
@@ -113,9 +113,9 @@ be run automatically.
### mission_scheduler/export
-**Service Type:** [cpr_mission_scheduler_msgs/srv/ExportData](definitions.mdx#scheduler-exportdata)
+**Service Type:** [clearpath_mission_scheduler_msgs/srv/ExportData](definitions.mdx#scheduler-exportdata)
-**Description:** Export all schedule data to a base64 string to it can be backed-up or copied to another robot.
+**Description:** Export all schedule data to a JSON string so it can be backed-up or copied to another robot.
:::note
@@ -153,25 +153,39 @@ exists, the returned object will have a blank UUID.
### mission_scheduler/import
-**Service Type:** [cpr_mission_scheduler_msgs/srv/ImportData](definitions.mdx#scheduler-importdata)
+**Service Type:** [clearpath_mission_scheduler_msgs/srv/ImportData](definitions.mdx#scheduler-importdata)
-**Description:** Import data exported by the `export_data` service. This will delete all schedules and replace the
-database contents with the imported data.
+**Description:** Import data exported by the `export_data` service. This will add new schedules to the database
+but will not modify or delete any existing schedules.
:::note
-This service is intended to be used in combination with the `export_data` service to facilitate backups or
-synchronizing schedules across multiple robots.
+This service is intended to be used in combination with the `export_data` service to facilitate deploying new
+schedules across multiple robots.
:::
### mission_scheduler/remove_mission
-**Service Type:** [cpr_mission_manager_msgs/srv/AddRemoveById](definitions.mdx#storage-addremovebyid)
+**Service Type:** [clearpath_mission_manager_msgs/srv/AddRemoveById](definitions.mdx#storage-addremovebyid)
**Description:** Remove the mission at a given position from a schedule, or remove all copies of a mission from a
schedule
+### mission_scheduler/restore
+
+**Service Type:** [cpr_mission_scheduler_msgs/srv/ImportData](definitions.mdx#scheduler-importdata)
+
+**Description:** Restore data exported by the `export_data` service. This will delete all schedules and replace the
+database contents with the imported data.
+
+:::note
+
+This service is intended to be used in combination with the `export_data` service to facilitate backups or
+synchronizing schedules across multiple robots.
+
+:::
+
### mission_scheduler/update_schedule
**Service Type:** [mission_scheduler/srv/UpdateSchedule](definitions.mdx#scheduler-updateschedule)
@@ -190,7 +204,7 @@ copy all values to the service request object, and then change the fields you wa
### mission_scheduler/run_now
-**Action Type:** [cpr_mission_scheduler_msgs/action/RunScheduleByUuid](definitions.mdx#scheduler-runschedulebyuuid)
+**Action Type:** [clearpath_mission_scheduler_msgs/action/RunScheduleByUuid](definitions.mdx#scheduler-runschedulebyuuid)
**Description:** Execute the schedule with the given UUID. The `delay` parameter will defer the execution by the
specified time. This action can be used to run a disabled schedule, or run a schedule at a time other than its
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 56cc335c..9ee7ab79 100644
--- a/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx
+++ b/docs_outdoornav_user_manual/integration_requirements/software_integration_instructions.mdx
@@ -51,7 +51,7 @@ The script in the sections below will reboot the computer it is run on.
For installations of the OutdoorNav software on the UGV computer (not a secondary or Starter Kit computer), run the following:
``` bash
-cd ~/cpr_outdoornav_launch/scripts
+cd ~/cpr_outdoornav_launch/scripts/
sudo ./setup_computers.sh
```
##### Secondary or Starter Kit Computer
@@ -59,14 +59,14 @@ sudo ./setup_computers.sh
Prior to running the script on the secondary or Starter Kit computer, ensure that you have the user and IP of the UGV computer that the secondary/starter kit computer is connected to. Run the following:
``` bash
-cd ~/cpr_outdoornav_launch/scripts
+cd ~/cpr_outdoornav_launch/scripts/
sudo ./setup_computers.sh -b
```
### Install OutdoorNav Software {#install-outdoornav}
``` bash
-cd ~/cpr_outdoornav_launch/scripts/
+cd ~/cpr_outdoornav_launch/
docker compose --profile outdoornav pull
```
@@ -101,11 +101,20 @@ nano outdoornav_tuning.env
### Start OutdoorNav
+For standard CPR UGVs (ie. not including Husky Observer), run the following to start OutdoorNav:
+
``` bash
cd ~/cpr_outdoornav_launch/ # directory with docker-compose.yaml
docker compose --profile outdoornav up -d --build
```
+For Husky Observers, run the following to start OutdoorNav:
+
+``` bash
+cd ~/cpr_outdoornav_launch/ # directory with docker-compose.yaml
+docker compose --profile outdoornav --profile power up -d --build
+```
+
### Test OutdoorNav Installation
1. Ping all of the network sensors to ensure proper communication with the UGV or secondary computer.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/pacs.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/pacs.mdx
index 325f91cc..1cba1a8b 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/pacs.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/pacs.mdx
@@ -81,7 +81,7 @@ Refer to the integration pages for our robots for more details:
| | [Axis M5525-E](sensors/cameras/axis_m5525_e.mdx) | 006758 | 027106 | 027225 | No |
| | [FLIR Blackfly S](sensors/cameras/flir_blackfly_s.mdx) | many | 027118 | 027218 | Yes |
| | [FLIR Ladybug5+](sensors/cameras/flir_ladybug5p.mdx) | 017245 | 028894 | 028893 | No |
-| | [Intel RealSense D435](sensors/cameras/realsense_d435.mdx) | 024150 | 026869 | 027208 | Yes |
+| | [Intel RealSense D435](sensors/cameras/realsense_d435.mdx) | 017103 | 026869 | 027208 | Yes |
| | [Occam Omni 60 Colour](sensors/cameras/occam_omni_60.mdx) | 019645 | 027102 | 027211 | No |
| | [Stereolabs ZED 2](sensors/cameras/stereolabs_zed_2.mdx) | 023611 | 028960 | 028959 | No |
| | [Stereolabs ZED 2i](sensors/cameras/stereolabs_zed_2.mdx) | 025844 | 026872 | 027210 | No |
diff --git a/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/cameras/realsense_d435.mdx b/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/cameras/realsense_d435.mdx
index adf00420..f09f846f 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/cameras/realsense_d435.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/accessories/sensors/cameras/realsense_d435.mdx
@@ -17,7 +17,7 @@ import Support from "/components/support.mdx";
| Description | CPR Item | Sales Kit | Installation Kit, With Fasteners |
| :-------------------------- | :------------------------------------------------------: | :-------: | :------------------------------: |
-| Intel RealSense D435 sensor | [024150](/assets/pdf/clearpath_robotics_024150-TDS1.pdf) | 026869 | 027208 |
+| Intel RealSense D435 sensor | [017103](/assets/pdf/clearpath_robotics_017103-TDS1.pdf) | 026869 | 027208 |
---
@@ -57,8 +57,8 @@ import Support from "/components/support.mdx";
## Further Reading
1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/intel-realsense-d435)
-2. [Datasheet](/assets/pdf/clearpath_robotics_024150-TDS1.pdf)
-3. [Dimensions](/assets/pdf/clearpath_robotics_024150-TDS3.pdf)
-4. [User Manual](/assets/pdf/clearpath_robotics_024150-TDS2.pdf)
+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_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
index 4dde9be6..4021e519 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/husky/integration_husky/integration_husky.mdx
@@ -184,7 +184,7 @@ Contact [Support](#support) for details.
:::caution
This is a single channel Stop loop, being monitored by a microcontroller.
-The when the microcontroller is in a Stop state; it will open relays which supply power to the Husky's motor controllers.
+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.
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
index a067dfaa..0918b81b 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
@@ -25,7 +25,7 @@ Refer to the [Extrusion Rails](extrusion_rails_warthog.mdx) page for further det
| Description | Sales Kit |
| :--------------------------------------------- | :-------: |
-| Installation—Extrusion Cross-Bar, 25 X 50, 655 | 028455 |
+| Installation—Extrusion Cross-Bar, 25 X 50, 652 | 028455 |
## Parts List
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 ac83f7f5..beadab44 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
@@ -16,10 +16,10 @@ The extrusions are attached to the Warthog using M6×1 stainless steel screws, a
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) | |
+| 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) |
@@ -71,7 +71,7 @@ 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 8 Blocks per beam if your application requires a stiffer base.
+You can install up to 7 Blocks per beam if your application requires a stiffer base.
:::
diff --git a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
index 2d98ae94..e1ad6c6f 100644
--- a/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
+++ b/docs_versioned_docs/version-ros1noetic/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
@@ -12,18 +12,6 @@ sidebar_position: 3
The top plates for the Warthog include M5×0.8 threaded holes that match the Clearpath PACS™ standard.
-:::note
-
-These top plates require [extrusion rails](extrusion_rails_warthog.mdx) to be mounted on the Warthog.
-
-:::
-
-:::note
-
-You can install an [extrusion cross-bar](extrusion_crossbar_warthog.mdx) under the top plates to add stiffness.
-
-:::
-
---
## Sales Kits
@@ -48,11 +36,12 @@ Refer to the [Crossbar](extrusion_crossbar_warthog.mdx) page for further details
## 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 14, Stainless Steel | 023471 | 9 |
+| 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
@@ -78,7 +67,7 @@ Place the Plate _(ID1)_ ontop of the Extrusion Rails and Crossbar. The Plate's c
### Step 3
-Install Screws _(ID3)_ into the Plate's holes; threading the Screws into the T-slop nuts from _Step 1_.
+Install Screws _(ID3)_ and _(ID4)_ into the Plate's holes; threading the Screws into the T-slot nuts from _Step 1_.
:::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 6fb8d203..a790402f 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
@@ -1580,7 +1580,8 @@ Disable any exisitng pan limits by opening the limits menu and making sure all t
-Move the camera to a pan of -179 degrees. The easiest way to move the camera precisely is to launch the ROS driver on the Main Computer and use the `cmd` topic to move the camera:
+Move the camera to a pan of -179 degrees. The easiest way to move the camera precisely is to launch the ROS driver on the Main Computer and use the `cmd` topic to move the camera.
+Note that the driver expects the pan and tilt angles to be in radians.
```bash
# Start the driver in one terminal
@@ -1588,7 +1589,7 @@ Move the camera to a pan of -179 degrees. The easiest way to move the camera pre
roslaunch axis_camera axis.launch enable_ptz:=true username:=root password:=clearpath hostname:=192.168.131.10
# In a second terminal, run
-rostopic pub /axis/cmd axis_camera/Axis "{pan: -179.0, tilt: 0.0, zoom: 1.0, focus: 0.0, brightness: 1.0, iris: 0.0, autofocus: true, autoiris: true}" -1
+rostopic pub /axis/cmd/position axis_msgs/Ptz "{pan: -3.12414, tilt: 0.0, zoom: 1.0}" -1"
```
Once the camera finishes moving, set the left pan limit by pressing the left limit button:
@@ -1606,7 +1607,7 @@ Once the camera finishes moving, set the left pan limit by pressing the left lim
Then move the camera to a pan of 179 degrees:
```bash
-rostopic pub /axis/cmd axis_camera/Axis "{pan: 179.0, tilt: 0.0, zoom: 1.0, focus: 0.0, brightness: 1.0, iris: 0.0, autofocus: true, autoiris: true}" -1
+rostopic pub /axis/cmd/position axis_msgs/Ptz "{pan: 3.12414, tilt: 0.0, zoom: 1.0}" -1"
```
Once the camera finishes moving, click on the right pan limit button to set the right pan limit to 179 degrees.
@@ -1624,6 +1625,17 @@ Once the camera finishes moving, click on the right pan limit button to set the
Click the Done button to apply the new limits. Note that the camera will now have a 2-degree deadzone at the rear where
it cannot point. This is an unfortunate but unavoidable side-effect of setting the limits this way.
+::: note
+
+In version `0.5.0` onward the `axis_camera` ROS driver uses radians instead of degrees. If you have an older version of the driver
+installed, you can set the pan angles with this command instead:
+
+```bash
+rostopic pub /axis/cmd axis_camera/Axis "{pan: 179.0, tilt: 0.0, zoom: 1.0, focus: 0.0, brightness: 1.0, iris: 0.0, autofocus: true, autoiris: true}" -1
+```
+
+:::
+
### RealSense Front and Rear Rear Driving Camera Configuration
#### Key Settings
diff --git a/docs_versioned_docs/version-ros2humble/components/_clearpath_firmware.mdx b/docs_versioned_docs/version-ros2humble/components/_clearpath_firmware.mdx
new file mode 100644
index 00000000..369f27bb
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/components/_clearpath_firmware.mdx
@@ -0,0 +1,156 @@
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+:::caution
+
+Before flashing firmware, place your robot up on blocks. 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
+
+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 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.
+
+
+
+
+
+ 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.
+
+
+
+
+
+#### 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.
+
+
+
diff --git a/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/bumper.mdx b/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/bumper.mdx
new file mode 100644
index 00000000..c09acdf2
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/components/yaml/attachments/a200/bumper.mdx
@@ -0,0 +1,33 @@
+
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/controllers.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/controllers.mdx
index 2af69a7e..e7312027 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/controllers.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/add-ons/controllers.mdx
@@ -23,7 +23,7 @@ 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.mdx).
+Depending on the robot platform and related controller, you will need to configure your robot's [robot.yaml configuration file](../../../ros/config/yaml/platform.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
index 543e4401..acc03940 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/pacs.mdx
@@ -81,7 +81,7 @@ Refer to the integration pages for our robots for more details:
| | [Axis M5525-E](sensors/cameras/axis_m5525_e.mdx) | 006758 | 027106 | 027225 |
| | [FLIR Blackfly S](sensors/cameras/flir_blackfly_s.mdx) | many | 027118 | 027218 |
| | [FLIR Ladybug5+](sensors/cameras/flir_ladybug5p.mdx) | 017245 | 028894 | 028893 |
-| | [Intel RealSense D435](sensors/cameras/realsense_d435.mdx) | 024150 | 026869 | 027208 |
+| | [Intel RealSense D435](sensors/cameras/realsense_d435.mdx) | 017103 | 026869 | 027208 |
| | [Occam Omni 60 Colour](sensors/cameras/occam_omni_60.mdx) | 019645 | 027102 | 027211 |
| | [Stereolabs ZED 2](sensors/cameras/stereolabs_zed_2.mdx) | 023611 | 028960 | 028959 |
| | [Stereolabs ZED 2i](sensors/cameras/stereolabs_zed_2.mdx) | 025844 | 026872 | 027210 |
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/flir_blackfly_s.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/flir_blackfly_s.mdx
index 8520789b..ece1ffd2 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/flir_blackfly_s.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/flir_blackfly_s.mdx
@@ -40,7 +40,7 @@ import Support from "/components/support.mdx";
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.mdx#cameras).
+[robot configuration yaml](../../../../ros/config/yaml/sensors.mdx#cameras).
This sensor also requires additional changes beyond the robot.yaml file. These changes are included by default in the
Clearpath ISO, but can also be applied using the following command:
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/realsense_d435.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/realsense_d435.mdx
index 4718d0c3..cd583258 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/realsense_d435.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/cameras/realsense_d435.mdx
@@ -4,6 +4,7 @@ sidebar_position: 6
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/intel_realsense.mdx";
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.mdx#cameras).
+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.mdx).
---
@@ -57,8 +59,8 @@ This allows you to add or remove the sensor from your robot's software descripti
## Further Reading
1. [Clearpath Robotics Store](https://store.clearpathrobotics.com/collections/vision/products/intel-realsense-d435)
-2. [Datasheet](/assets/pdf/clearpath_robotics_024150-TDS1.pdf)
-3. [Dimensions](/assets/pdf/clearpath_robotics_024150-TDS3.pdf)
-4. [User Manual](/assets/pdf/clearpath_robotics_024150-TDS2.pdf)
+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_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/garmin_gps_18x.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/garmin_gps_18x.mdx
index 6e4d9a0a..6803341a 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/garmin_gps_18x.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/garmin_gps_18x.mdx
@@ -4,6 +4,7 @@ sidebar_position: 1
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/garmin_18x.mdx";
-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.
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/swift_navigation_duro.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/swift_navigation_duro.mdx
index 54b0951f..adfce5dd 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/swift_navigation_duro.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/gps/swift_navigation_duro.mdx
@@ -4,6 +4,7 @@ sidebar_position: 2
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/swiftnav_duro.mdx";
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.mdx#gps).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx
index 1121c75f..123dc9dc 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/microstrain_3dm_gx5.mdx
@@ -4,6 +4,7 @@ sidebar_position: 1
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/microstrain_imu.mdx";
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.mdx#imu).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/redshift_labs_um7.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/redshift_labs_um7.mdx
index 7f66c9e1..c1704195 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/redshift_labs_um7.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/imu/redshift_labs_um7.mdx
@@ -4,6 +4,7 @@ sidebar_position: 2
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/redshift_um7.mdx";
-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.
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx
index 398bc1fb..09614312 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust10_lx.mdx
@@ -4,6 +4,7 @@ sidebar_position: 1
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
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.mdx#lidar-2d).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx
index 00915b60..61c62a80 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust20_lx.mdx
@@ -4,6 +4,7 @@ sidebar_position: 2
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
-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.
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx
index 131dffde..5df721fb 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/hokuyo_ust30_lx.mdx
@@ -4,6 +4,7 @@ sidebar_position: 3
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
-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.
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/sick_lms111.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/sick_lms111.mdx
index a9120aea..4b073568 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/sick_lms111.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_2d/sick_lms111.mdx
@@ -4,6 +4,7 @@ sidebar_position: 4
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/sick_lms1xx.mdx";
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.mdx#lidar-2d).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx
index a18ca897..4046d9a7 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck hi_res.mdx
@@ -4,6 +4,7 @@ sidebar_position: 3
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
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.mdx#lidar-3d).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx
index b93d78d5..35509eeb 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck.mdx
@@ -4,6 +4,7 @@ sidebar_position: 2
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
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.mdx#lidar-3d).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx
index bfe57713..e7c2396c 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_puck_lite.mdx
@@ -4,6 +4,7 @@ sidebar_position: 1
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
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.mdx#lidar-3d).
+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.mdx).
---
diff --git a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx
index 6341f8a0..39febe86 100644
--- a/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/accessories/sensors/lidar_3d/velodyne_ultra_puck.mdx
@@ -4,6 +4,7 @@ sidebar_position: 4
---
import Support from "/components/support.mdx";
+import YAML from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
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.mdx#lidar-3d).
+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.mdx).
---
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 b2ad724f..7edc1750 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
@@ -185,7 +185,7 @@ Contact [Support](#support) for details.
:::caution
This is a single channel Stop loop, being monitored by a microcontroller.
-The when the microcontroller is in a Stop state; it will open relays which supply power to the Husky's motor controllers.
+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.
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
index a067dfaa..0918b81b 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/extrusion_crossbar_warthog.mdx
@@ -25,7 +25,7 @@ Refer to the [Extrusion Rails](extrusion_rails_warthog.mdx) page for further det
| Description | Sales Kit |
| :--------------------------------------------- | :-------: |
-| Installation—Extrusion Cross-Bar, 25 X 50, 655 | 028455 |
+| Installation—Extrusion Cross-Bar, 25 X 50, 652 | 028455 |
## Parts List
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 ac83f7f5..beadab44 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
@@ -16,10 +16,10 @@ The extrusions are attached to the Warthog using M6×1 stainless steel screws, a
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) | |
+| 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) |
@@ -71,7 +71,7 @@ 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 8 Blocks per beam if your application requires a stiffer base.
+You can install up to 7 Blocks per beam if your application requires a stiffer base.
:::
diff --git a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
index 2d98ae94..e1ad6c6f 100644
--- a/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
+++ b/docs_versioned_docs/version-ros2humble/robots/outdoor_robots/warthog/integration_warthog/kits_warthog/top_plate_warthog.mdx
@@ -12,18 +12,6 @@ sidebar_position: 3
The top plates for the Warthog include M5×0.8 threaded holes that match the Clearpath PACS™ standard.
-:::note
-
-These top plates require [extrusion rails](extrusion_rails_warthog.mdx) to be mounted on the Warthog.
-
-:::
-
-:::note
-
-You can install an [extrusion cross-bar](extrusion_crossbar_warthog.mdx) under the top plates to add stiffness.
-
-:::
-
---
## Sales Kits
@@ -48,11 +36,12 @@ Refer to the [Crossbar](extrusion_crossbar_warthog.mdx) page for further details
## 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 14, Stainless Steel | 023471 | 9 |
+| 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
@@ -78,7 +67,7 @@ Place the Plate _(ID1)_ ontop of the Extrusion Rails and Crossbar. The Plate's c
### Step 3
-Install Screws _(ID3)_ into the Plate's holes; threading the Screws into the T-slop nuts from _Step 1_.
+Install Screws _(ID3)_ and _(ID4)_ into the Plate's holes; threading the Screws into the T-slot nuts from _Step 1_.
:::note
diff --git a/docs_versioned_docs/version-ros2humble/ros/api/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/api/overview.mdx
index bf9c11c5..5f1ee68e 100644
--- a/docs_versioned_docs/version-ros2humble/ros/api/overview.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/api/overview.mdx
@@ -95,4 +95,4 @@ used the same topic, then they would both drive when a message is published to t
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.mdx) file.
+will be `a200_0001`. This can be overwritten in the [robot.yaml](../config/yaml/overview.mdx) file.
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml.mdx
deleted file mode 100644
index f734f76d..00000000
--- a/docs_versioned_docs/version-ros2humble/ros/config/yaml.mdx
+++ /dev/null
@@ -1,1195 +0,0 @@
----
-title: Robot YAML
-sidebar_label: Robot YAML
-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 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. [**links**](#links) 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.
-
-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-sample)
-2. [**System Sample**](#system-sample)
-3. [**Platform Sample**](#platform-sample)
-4. [**Links Sample**](#links-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.mdx#introduction): `a200-0000`
-2. [Jackal J100](../../robots/outdoor_robots/jackal/user_manual_jackal.mdx#introduction): `j100-0000`
-
-Every robot platform has specific [attachments](#attachments), 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`.**
-- **workspaces** indicates a list of workspaces that need to be sourced by specifying the path to the setup.py
-
-### 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
- 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
-
-
-
-
-
-
-## Platform
-
-Every robot platform has unique structures such as versatile sensor mounting solutions, wireless charging receivers, and waterproofing enclosures; we refer to these as attachments.
-
-#### Joystick Controller
-We support two types of controllers:
- - **ps4**: standard Playstation4 controller.
- - **logitech**: Logitech F710
-
-```yaml
-controller: ps4 # or logitech
-```
-
-#### Attachments
-
-There are four types of attachments:
-
-1. **bumpers** modify the front face and rear face of the robot platform.
-2. **fenders** modify the area above the wheels on the front and rear of the platform.
-3. **top_plates** modify the top face of the robot platform.
-4. **structures** are large custom parts that are added atop the top plate.
-
-#### Husky A200 {#attachments-a200}
-
-The **Husky A200** has a few models for each of it's attachments:
-
-- **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 {#attachments-j100}
-
-The **Jackal J100** currently only has customization options with it's fenders.
-
-- **fenders** can be swapped from the `default` model to the `sensor` model that has a mounting location for a small lidar or camera.
-
-```yaml
-front_fender:
- enabled: true # or false
- model: default # or sensor
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
-rear_fender:
- enabled: true # or false
- model: default # or sensor
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 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 and pass in and overwrite parameters to all platform nodes.
-Extras have the following entries:
-
-- **urdf:** absolute path to URDF to add to robot platform 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: null # /absolute/path/to/urdf
- ros_parameters: {} # node parameter
-```
-
-#### 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
-```
-
-#### 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
- attachments:
- 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
- ros_parameters: {}
-```
-
-
-
-
-## Links
-
-Links are any URDF primitive:
-
-1. **frame** in the URDF without any geometry, i.e. just a frame.
-
-```yaml
-frame:
- - 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 link directly through the `robot.yaml`.
-
-Just as is the case in URDF, links are added 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.
-
-### Sample {#links-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: []
-```
-
-
-
-
-## 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
-```
-
-- **sick:** are mounts specifically designed to mount SICK LiDARs. The orientation of the LiDAR on the mount can be set to either `upright` or `inverted`.
-```yaml
-sick:
- - parent: base_link
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- model: inverted # or upright
-```
-
-- **post:** are vertical extrusion rails to which sensors can be added.
-```yaml
-post:
- - parent: base_link
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
- model: single # or dual or quad
- spacing: 0.08 # distance between multiple posts if model is dual or quad
- height: 0.075 # height of post
-```
-
-- **disk:** are circular plates which are used to mount circular sensors, i.e. the Velodyne
-```yaml
-disk:
- - parent: base_link
- xyz: [0.0, 0.0, 0.0]
- rpy: [0.0, 0.0, 0.0]
-```
-
-### 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:
- 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:
- camera:
- 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:
- camera:
- 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/_category_.json b/docs_versioned_docs/version-ros2humble/ros/config/yaml/_category_.json
new file mode 100644
index 00000000..22da6966
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Robot YAML",
+ "position": 1
+}
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx
new file mode 100644
index 00000000..83a9dd42
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/links.mdx
@@ -0,0 +1,96 @@
+---
+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.
+
+If you prefer to add a URDF instead, then you can link it directly through the `platform.extras` 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_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx
new file mode 100644
index 00000000..60208c18
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/mounts.mdx
@@ -0,0 +1,181 @@
+---
+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.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_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx
new file mode 100644
index 00000000..95a3b87c
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/overview.mdx
@@ -0,0 +1,186 @@
+---
+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.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.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.mdx#sample)
+4. [**Links Sample**](./links.mdx#sample)
+5. [**Mounts Sample**](./mounts.mdx#sample)
+6. [**Sensors Sample**](./sensors.mdx#sample)
+
+Sample A200 YAML
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform.mdx
new file mode 100644
index 00000000..1431088f
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/platform.mdx
@@ -0,0 +1,301 @@
+---
+title: Platform
+sidebar_label: Platform
+sidebar_position: 4
+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";
+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";
+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";
+
+Every robot platform has unique structures such as versatile sensor mounting solutions, wireless charging receivers, and waterproofing enclosures; we refer to these as **attachments**.
+
+## Joystick Controller
+We support two types of controllers:
+ - **ps4**: standard Playstation4 controller.
+ - **logitech**: Logitech F710
+
+```yaml
+controller: ps4 # or logitech
+```
+
+## Attachments
+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` links at which these attachments are added; however, the `parent` link can be change to wherever you'd want the attachment 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.
+
+### Husky A200
+
+#### 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
+
+
+
+## Jackal J100 {#attachments-j100}
+
+### 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
+
+
+
+## Warthog W200 {#attachments-w200}
+
+### 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.
+
+
+
+### Generators
+
+
+## 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 and pass in and overwrite parameters to all platform nodes.
+Extras have the following entries:
+
+- **urdf:** absolute path to URDF to add to robot platform 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: null # /absolute/path/to/urdf
+ ros_parameters: {} # node parameter
+```
+
+### 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
+```
+
+## 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: mid_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: mid_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:
+ 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: mid_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: mid_mount
+ xyz: [0.0, 0.0, 0.0]
+ rpy: [0.0, 0.0, 0.0]
+ enabled: true
+ extras:
+ urdf: null
+ ros_parameters: {}
+```
+
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors.mdx
new file mode 100644
index 00000000..21efb9bd
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/sensors.mdx
@@ -0,0 +1,238 @@
+---
+title: Sensors
+sidebar_label: Sensors
+sidebar_position: 7
+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 Garmin18x from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/garmin_18x.mdx";
+import HokuyoUST from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/hokuyo_ust.mdx";
+import IntelRealsense from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/intel_realsense.mdx";
+import MicrostrainIMU from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/microstrain_imu.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 RedShiftUM7 from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/redshift_um7.mdx";
+import SickLMS1xx from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/sick_lms1xx.mdx";
+import SwiftNavDuro from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/swiftnav_duro.mdx";
+import VelodyneLidar from "/docs_versioned_docs/version-ros2humble/components/yaml/sensors/velodyne_lidar.mdx";
+
+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:** publish **_sensor_msgs/Image_** messages
+- **GPS:** publish **_sensor_msgs/NavSatFix_** messages
+- **IMU:** publish **_sensor_msgs/Imu_** messages
+- **LiDAR 2D:** publish **_sensor_msgs/LaserScan_** messages
+- **LiDAR 3D:** 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.
+
+## Cameras
+### Intel Realsense
+
+
+## GPS
+### SwiftNav Duro
+
+
+### Garmin 18X
+
+
+## Novatel Smart6
+
+
+## Novatel Smart7
+
+
+## IMU
+### Microstrain IMU
+
+
+### CHRobotics UM6
+
+
+### Redshift UM7
+
+
+## LiDAR 2D
+### Hokuyo UST
+
+
+### SICK LMS1xx
+
+
+## LiDAR 3D
+### Velodyne Lidar
+
+
+## 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:
+ camera:
+ 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:
+ camera:
+ 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
new file mode 100644
index 00000000..3b2f2a2b
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/serial.mdx
@@ -0,0 +1,26 @@
+---
+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/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`
+
+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`.
+
+## 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_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx b/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx
new file mode 100644
index 00000000..d8ee2cc1
--- /dev/null
+++ b/docs_versioned_docs/version-ros2humble/ros/config/yaml/system.mdx
@@ -0,0 +1,69 @@
+---
+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.
+
+## 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 the hostname of the computer this configuration file will be loaded 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 computer.
+
+## ROS 2 Environment
+
+The **ros2** sections is necessary to setup the ROS 2 middleware.
+
+- **username** must match the username that is used to run all ROS nodes.
+- **namespace** 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** specifies the ROS 2 domain ID to use.
+- **rmw_implementation** specifies the ROS 2 middleware to use. **Currently, it only supports `rmw_fastrtps_cpp`.**
+- **workspaces** indicates a list of workspaces that need to be sourced by specifying the path to the setup.py
+
+## 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`.
+
+Note that this configuration YAML is meant to be on that primary computer, hence `self: cpr-a200-0000`.
+
+By default, all Clearpath robots use the 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
+ 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 6fb7f5ae..d99863ea 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.mdx) file. See, [Joystick Controller](../config/yaml.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.mdx#joystick-controller) setup in the Clearpath Configuration.
:::
diff --git a/docs_versioned_docs/version-ros2humble/ros/installation/remote_pc.mdx b/docs_versioned_docs/version-ros2humble/ros/installation/remote_pc.mdx
index 99a68155..e0d5c45e 100644
--- a/docs_versioned_docs/version-ros2humble/ros/installation/remote_pc.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/installation/remote_pc.mdx
@@ -40,7 +40,7 @@ This package will install launch and configuration files for visualising and int
### Setup Folder
-The remote computer will need a copy of the [robot.yaml](../config/yaml.mdx) file to generate the same `setup.bash`
+The remote 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**
@@ -78,4 +78,4 @@ source ~/clearpath/setup.bash
You may get the warning `bash: /home/administrator/micro_ros_ws/install/setup.bash: No such file or directory` when you source
this file. This is not a concern on the remote computer. The micro ROS workspace is only required on the primary computer.
-:::
\ No newline at end of file
+:::
diff --git a/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx b/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
index 93baffa6..ee3fead4 100644
--- a/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/installation/robot.mdx
@@ -6,7 +6,7 @@ toc_min_heading_level: 2
toc_max_heading_level: 4
---
-import JackalFirmware from "../../components/_jackal_firmware.mdx";
+import ClearpathFirmware from "../../components/_clearpath_firmware.mdx";
import StandardClearpathBridgeSetup from "../../components/_standard_clearpath_bridge_setup.mdx";
import ComputerNetworkingSetupInstall from "../../components/_computer_networking_setup_install.mdx";
@@ -85,9 +85,7 @@ You should now be able to SSH into the robot by calling `ssh administrator@
+
## Package Install
@@ -109,7 +107,7 @@ For details on setting up custom network interface settings see [Clearpath Compu
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.mdx) section. This YAML is used to generate the launch,
+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.
@@ -125,14 +123,12 @@ To start the services, call
sudo systemctl daemon-reload && sudo systemctl start clearpath-robot.service
```
-#### 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).
-
### 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)
@@ -222,22 +218,22 @@ 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.mdx#ros-2-environment) section.
+in the [ROS2 Environment](../config/yaml/system.mdx#ros-2-environment) section.
:::
#### Setup folder
-Create the setup folder where the [robot.yaml](../config/yaml.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 666 /etc/clearpath/
+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.mdx) section. This YAML is used to generate the launch,
+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/`.
@@ -249,6 +245,7 @@ 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
@@ -270,4 +267,6 @@ source /etc/clearpath/setup.bash
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).
\ No newline at end of file
+listed under [software bringup](../../robots/accessories/sensors/cameras/flir_blackfly_s#software-bringup).
+
+
diff --git a/docs_versioned_docs/version-ros2humble/ros/installation/upgrading.mdx b/docs_versioned_docs/version-ros2humble/ros/installation/upgrading.mdx
index 888b61f8..c59601a0 100644
--- a/docs_versioned_docs/version-ros2humble/ros/installation/upgrading.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/installation/upgrading.mdx
@@ -124,19 +124,19 @@ If this is not the case, it is the responsibility of the user to ensure that any
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 (e.g. `JACKAL_URDF_EXTRAS`) and have stored them outside any of the folders specified above, you must
+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.mdx) for more details.
+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.mdx#platform) section of the `robot.yaml` file.
+now reside under the [platform](../config/yaml/platform.mdx) section of the `robot.yaml` file.
@@ -225,7 +236,7 @@ platform:
### Sensors
-Sensors can be added under the [sensors](../config/yaml.mdx#sensors) key in the `robot.yaml` file. There is no longer
+Sensors can be added under the [sensors](../config/yaml/sensors.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).
@@ -299,7 +310,7 @@ sensors:
default
>
-Environment variables:
+Environment variables:
```
# Primary Laser
@@ -429,7 +440,7 @@ sensors:
default
>
-Environment variables:
+Environment variables:
```
export JACKAL_LASER_3D=1
@@ -709,4 +720,4 @@ sensors:
## 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.
\ No newline at end of file
+the [robot install instructions](robot.mdx). This will involve installing the new OS.
diff --git a/docs_versioned_docs/version-ros2humble/ros/tutorials/simulator/install.mdx b/docs_versioned_docs/version-ros2humble/ros/tutorials/simulator/install.mdx
index ceee4f10..19c859a7 100644
--- a/docs_versioned_docs/version-ros2humble/ros/tutorials/simulator/install.mdx
+++ b/docs_versioned_docs/version-ros2humble/ros/tutorials/simulator/install.mdx
@@ -63,6 +63,6 @@ colcon build --symlink-install
:::note
-Make sure to add the workspace to your [robot.yaml](../../config/yaml.mdx#system) file.
+Make sure to add the workspace to your [robot.yaml](../../config/yaml/system.mdx) file.
:::
diff --git a/static/assets/pdf/clearpath_robotics_024150-TDS1.pdf b/static/assets/pdf/clearpath_robotics_017103-TDS1.pdf
similarity index 99%
rename from static/assets/pdf/clearpath_robotics_024150-TDS1.pdf
rename to static/assets/pdf/clearpath_robotics_017103-TDS1.pdf
index 7990125a..9e963eb0 100644
Binary files a/static/assets/pdf/clearpath_robotics_024150-TDS1.pdf and b/static/assets/pdf/clearpath_robotics_017103-TDS1.pdf differ
diff --git a/static/assets/pdf/clearpath_robotics_024150-TDS2.pdf b/static/assets/pdf/clearpath_robotics_017103-TDS2.pdf
similarity index 97%
rename from static/assets/pdf/clearpath_robotics_024150-TDS2.pdf
rename to static/assets/pdf/clearpath_robotics_017103-TDS2.pdf
index a68d62bb..fd67e9da 100644
Binary files a/static/assets/pdf/clearpath_robotics_024150-TDS2.pdf and b/static/assets/pdf/clearpath_robotics_017103-TDS2.pdf differ
diff --git a/static/assets/pdf/clearpath_robotics_024150-TDS3.pdf b/static/assets/pdf/clearpath_robotics_017103-TDS3.pdf
similarity index 99%
rename from static/assets/pdf/clearpath_robotics_024150-TDS3.pdf
rename to static/assets/pdf/clearpath_robotics_017103-TDS3.pdf
index af48ae12..bd1188c9 100644
Binary files a/static/assets/pdf/clearpath_robotics_024150-TDS3.pdf and b/static/assets/pdf/clearpath_robotics_017103-TDS3.pdf differ
diff --git a/static/assets/pdf/clearpath_robotics_028451.pdf b/static/assets/pdf/clearpath_robotics_028451.pdf
index 33050a91..77d759bc 100644
Binary files a/static/assets/pdf/clearpath_robotics_028451.pdf and b/static/assets/pdf/clearpath_robotics_028451.pdf differ
diff --git a/static/assets/pdf/clearpath_robotics_028459.pdf b/static/assets/pdf/clearpath_robotics_028459.pdf
index a4d6e2c5..18633c56 100644
Binary files a/static/assets/pdf/clearpath_robotics_028459.pdf and b/static/assets/pdf/clearpath_robotics_028459.pdf differ
diff --git a/static/img/robot_images/warthog_images/warthog_pacs_1.png b/static/img/robot_images/warthog_images/warthog_pacs_1.png
index bdf00730..6ac38bb4 100644
Binary files a/static/img/robot_images/warthog_images/warthog_pacs_1.png and b/static/img/robot_images/warthog_images/warthog_pacs_1.png differ
diff --git a/static/img/robot_images/warthog_images/warthog_pacs_2.png b/static/img/robot_images/warthog_images/warthog_pacs_2.png
index bc1d6cef..ed7fb9ce 100644
Binary files a/static/img/robot_images/warthog_images/warthog_pacs_2.png and b/static/img/robot_images/warthog_images/warthog_pacs_2.png differ
diff --git a/static/img/robot_images/warthog_images/warthog_pacs_3.png b/static/img/robot_images/warthog_images/warthog_pacs_3.png
index e3c11bcc..f2373d58 100644
Binary files a/static/img/robot_images/warthog_images/warthog_pacs_3.png and b/static/img/robot_images/warthog_images/warthog_pacs_3.png differ
+ 
+ ![]({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/fender_default.png").default})
+![]({require("./img/fender_sensor.png").default})
+![]({require("./img/top_plate_ark_enclosure.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/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/garmin_18x.png").default})
+![]({require("./img/hokuyo_ust.png").default})
+![]({require("./img/intel_realsense.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/swiftnav_duro.png").default})
+![]({require("./img/velodyne_lidar.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_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})
- ![]({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_sensors_0.png").default})
+ ![]({require("../img/husky_sensors_1.png").default})
+ ![]({require("../img/husky_sensors_2.png").default})
+