* The **Time** status can degrade afterwards (e.g. after entering a building). This will not impact the ability to start capturing data when **FineSteering** has been achieved at least once after Rover has started. ## Things to check * Make sure that the correct LiDAR, IMU, and GPS antenna (if applicable) mounting calibrations are set up before starting processing. If not, it is a good idea to **Save as...** the project after setting them up, in order to avoid the need to repeat entering them next time. * Make sure that in the **Manage SLAM...** menu, **Fuse SLAM cloud** and **Automatically refresh poses** are checked (the default settings).  * At the starting location, SLAM performs 'bootstrapping', i.e. creating the initial map of the surroundings (the first few seconds when the sensor is aligning and creating an understanding of the surroundings to tie to further along the mission.) * When a trajectory re-visits the same area (*a loop*), the two parts of the trajectory should be correctly registered one against the other. This can be verified at the point cloud-level by coloring the cloud by time or by *submap ID*, and making sure that the old and new points in the cloud are well intermixed, without separation.  Another helpful way to verify loop closure at trajectory-level is to enable **Manage SLAM... -> Display loop closure constraints**. Different parts of the trajectory which visit the same area should have lines of different colors connecting them.  * If the accumulated drift gets too large (e.g. in a large loop), loop closures may be missed. This can be countered by increasing the loop closure search windows in the **SLAM tuning** dialog when starting SLAM processing. (Setting the search windows too large may increase the processing time and cause problems in tighter and symmetric environments, e.g. building with similar rooms or similar floors).  ## Fine tuning After SLAM processing is finished, using the option **Manage SLAM...** -> **Adjust optimization weights**, some final non-destructive tweaking of the trajectory optimization can be performed. Notably, the strength of georeferencing can be adjusted (if it is too high, it can impact the cloud quality; if it is too low, the cloud may not be accurately georeferenced). The georeferencing inlier scale specifies the distance from trajectory at which GPS measurement start having diminishing effect. This parameter can be set to a smaller distance at the very end in order to eliminate the effect of outlier measurements. The gravity alignment weight (1) performs global gravity (i.e. pitch/roll) alignment of the trajectory according to the IMU measurements, while also having a "smoothing" effect on the trajectory positions. Gravity alignment (2) is an alternative implementation of the same (albeit it should not have the "smoothing" effect). In our testing, a moderate (10-200) weight on the gravity alignment 1 has proven to work.  To apply changes and see the immediate effect on the trajectory and the cloud, click **Optimize**. For changing other settings in the SLAM tuning, the dataset must be reprocessed. ## Troubleshooting * When troubleshooting, the first step is to set the georefencing strength to 0 (zero) and to perform SLAM processing again.  * If the SLAM trajectory and the cloud look correct, try restoring/adjusting the georeferencing strength at this point using the **Optimization weights** section of the **SLAM** window and then pressing **Optimize**.  * If still problematic, try processing with the "LFTB2 no opt" preset, still making sure that the georeferencing strength is at 0 after loading the preset. Process a portion of the dataset. The trajectory and cloud can have global pitch roll, and drift at this point; however, the local cloud quality should be acceptable.  * Next, pressing **Optimize** in the SLAM dialog should result in gravity alignment being performed; i.e. the pitch and roll of the trajectory should be optimized correctly. * Mounting the LiDAR with a noticeable pitch is not recommended for SLAM processing. However, in this scenario, the **Submap size (nr. of sweeps)** parameter can be increased from the default 150 scans to a bigger value (e.g. up to 1000 scans). It is also suggested to increase this parameter slightly (e.g. to 200-300) when data acquisition is performed on foot.  --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs-6.phoenixlidar.com/lidarmill-desktop/post-processing/slam-workflow-beta.md?ask=