diff --git a/README.md b/README.md
index 8e5db6a..477f79e 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
This is the public repo for the LUCI ROS2 SDK.
-All documentation for examples, packages, and use lives at https://lucimobility.github.io/luci-ros2-sdk-docs/
+All documentation for examples, packages, and use lives at https://lucimobility.github.io/luci-sdk-docs/
[Getting Started](docs/1_Getting-Started/1_getting-started.md)
diff --git a/docs/3_Examples/map.png b/docs/3_Examples/map.png
new file mode 100644
index 0000000..612819a
Binary files /dev/null and b/docs/3_Examples/map.png differ
diff --git a/docs/3_Examples/slam.md b/docs/3_Examples/slam.md
index a8b154a..df5a897 100644
--- a/docs/3_Examples/slam.md
+++ b/docs/3_Examples/slam.md
@@ -2,44 +2,81 @@
SLAM is a very useful application for autonomous or semi-autonomous robot navigation.
-LUCI as a sensor platform allows for a jump start on applying a SLAM methodology to power wheelchairs.
+LUCI as a sensor platform allows for a jump start on applying a SLAM methodology to power wheelchairs.
-While LUCI does not offer a existing SLAM package for the ROS2 SDK we have managed some level of prototype SLAM navigation ourselves.
+While LUCI does not offer a existing SLAM package for the ROS2 SDK we have managed some level of prototype SLAM navigation ourselves.
-In doing our own prototyping we have established a few tips for a successful navigation.
+In doing our own prototyping we have established a few tips for a successful navigation.
+
+## Methods
+
+There are multiple methods for SLAM
+Listed in the table below are some of the methods we have tried or looked at and their pros and cons.
+
+| Method | Pros | Cons |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| VSLAM (visual image landmarks) | Can be ran with no encoder
Can be used without imu
Resistent to the kidnapped robot problem | Struggles in featureless environment |
+| GMapping | Quality 2D map | AMCL Localization
LaserScan based |
+| Google Carographer | Protobuf / gRPC compatible
2D/3D Mapping
Aruco tag support | High CPU load |
+| RTabMap | RGB-D SLAM
Paired depth and tracking camera
Object detection | High CPU load |
+
+## Testing done
+
+LUCI has tested its ability to do SLAM with the following methods
+
+- Lidar
+- T265 Tracking camera
+- Full LUCI PointCloud
+- Camera only PointCloud
+- AHRS only Odom
+- Cartographer for localization
+- Tuning AMCL
+- RTabMap for localization
+- Server side processing (VM)
## Packages
-There are two main SLAM packages that have been tried with LUCI.
+
+There are two main SLAM packages that have been successful with LUCI.
1. [slam_toolbox](http://wiki.ros.org/slam_toolbox)
-2. [gmapping](http://wiki.ros.org/gmapping)
+2. [gmapping](http://wiki.ros.org/gmapping)
Both have their pros and cons but were able to be ran with LUCI data streams.
-## Data
+## Architecture
+
+Here is the architecture design of what was tested at the LUCI offices and what the resulting map looked like
+![Architecture](slam.png)
+
+![Map](map.png)
+
+## Data
+
#### 2D vs 3D
-While some of the SLAM nodes will expect a 2D point cloud and LUCI provides a 3D cloud you will need some method of converting our provided feed to 2D.
+
+While some of the SLAM nodes will expect a 2D point cloud and LUCI provides a 3D cloud you will need some method of converting our provided feed to 2D.
This can be done in a couple of ways.
1. Implement a z height flatten filter that casts all points to a single z height.
-2. Run through an existing pointcloud->lidar converter node. This one proved decent.
-[pointcloud_to_laserscan](https://github.com/ros-perception/pointcloud_to_laserscan)
+2. Run through an existing pointcloud->lidar converter node. This one proved decent.
+ [pointcloud_to_laserscan](https://github.com/ros-perception/pointcloud_to_laserscan)
-*Note: Not all SLAM nodes need 2D and 3D data is definitely the better choice to use for LUCI if able*
+_Note: Not all SLAM nodes need 2D and 3D data is definitely the better choice to use for LUCI if able_
Casting points to 2D produces a decent map but will struggle with localization later.
#### Ultrasonic Data
+
As LUCI produces ultrasonic curves as points it is recommended that you do NOT include them in the mapping of an environment as they will add curved noise to your map.
#### Odom
-Odometry data is critical to the success of SLAM and while it can be found many ways the most common is with IMU and encoders.
-LUCI does offer some Odom data through its onboard IMU but as all chairs that LUCI works with do NOT have wheel position sensors (*they operate on an open loop system*) LUCI is unable to offer any wheel position at this time.
+
+Odometry data is critical to the success of SLAM and while it can be found many ways the most common is with IMU and encoders.
+LUCI does offer some Odom data through its onboard IMU but as all chairs that LUCI works with do NOT have wheel position sensors (_they operate on an open loop system_) LUCI is unable to offer any wheel position at this time.
## JS to Twist Message
-As LUCI and wheelchairs operate with a left-right/forward-back joystick and SLAM packages expect a [Twist](http://docs.ros.org/en/melodic/api/geometry_msgs/html/msg/Twist.html) message a conversion node will be required.
-This is unfortunately the nature of a velocity based twist message and a linear JS incompatibility.
+As LUCI and wheelchairs operate with a left-right/forward-back joystick and SLAM packages expect a [Twist](http://docs.ros.org/en/melodic/api/geometry_msgs/html/msg/Twist.html) message a conversion node will be required.
Here are two different methods LUCI has played with to varying degrees of success that may be of help.
diff --git a/docs/3_Examples/slam.png b/docs/3_Examples/slam.png
new file mode 100644
index 0000000..b94bb7b
Binary files /dev/null and b/docs/3_Examples/slam.png differ