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