Pros of VINS-Mono

• Utilizes both visual and inertial data for more robust state estimation
• Supports loop closure for improved accuracy in long-term operation
• Provides a more comprehensive solution for visual-inertial odometry and mapping

Cons of VINS-Mono

• Higher computational complexity due to the fusion of multiple sensor inputs
• Requires careful calibration of both camera and IMU for optimal performance
• More sensitive to environmental conditions and sensor noise

Code Comparison

VINS-Mono (feature tracking):

void FeatureTracker::readImage(const cv::Mat &_img, double _cur_time)
{
    cv::Mat img;
    TicToc t_r;
    cur_time = _cur_time;

    if (EQUALIZE)
    {
        cv::Ptr<cv::CLAHE> clahe = cv::createCLAHE(3.0, cv::Size(8, 8));
        TicToc t_c;
        clahe->apply(_img, img);
        ROS_DEBUG("CLAHE costs: %fms", t_c.toc());
    }
    else
        img = _img;

A-LOAM (feature extraction):

void laserCloudHandler(const sensor_msgs::PointCloud2ConstPtr& laserCloudMsg)
{
    if (!systemInited)
    {
        systemInitCount++;
        if (systemInitCount >= systemDelay)
        {
            systemInited = true;
        }
        else
            return;
    }

    TicToc t_whole;
    TicToc t_prepare;

Pros of Cartographer

• Multi-sensor fusion: Supports various sensor types (LiDAR, IMU, odometry)
• Real-time performance: Optimized for online SLAM in real-time applications
• Large-scale mapping: Efficient for creating maps of large environments

Cons of Cartographer

• Complexity: More complex setup and configuration compared to A-LOAM
• Resource intensive: Requires more computational resources
• Learning curve: Steeper learning curve for new users

Code Comparison

A-LOAM (scan matching):

void laserCloudCornerLastHandler(const sensor_msgs::PointCloud2ConstPtr& laserCloudCornerLast2)
{
    timeLaserCloudCornerLast = laserCloudCornerLast2->header.stamp.toSec();
    laserCloudCornerLast->clear();
    pcl::fromROSMsg(*laserCloudCornerLast2, *laserCloudCornerLast);
}

Cartographer (scan matching):

void HandleLaserScan(const sensor_msgs::LaserScan::ConstPtr& msg) {
  carto::sensor::PointCloudWithIntensities point_cloud;
  carto::common::Time time;
  std::tie(point_cloud, time) = ToPointCloudWithIntensities(*msg);
  HandleLaserScanProto(time, msg->frame_id, point_cloud);
}

Both repositories focus on SLAM, but Cartographer offers more flexibility and features at the cost of increased complexity, while A-LOAM provides a simpler, LiDAR-focused solution.

Pros of LeGO-LOAM

• Improved performance in unstructured environments due to ground optimization
• Better loop closure detection for enhanced mapping accuracy
• More robust to sensor noise and dynamic objects

Cons of LeGO-LOAM

• Higher computational complexity, potentially slower in real-time applications
• More parameters to tune, which can be challenging for new users
• May struggle in environments with limited features or sparse point clouds

Code Comparison

A-LOAM:

void laserCloudHandler(const sensor_msgs::PointCloud2ConstPtr &laserCloudMsg)
{
    mBuf.lock();
    cloudQueue.push(laserCloudMsg);
    mBuf.unlock();
}

LeGO-LOAM:

void laserCloudHandler(const sensor_msgs::PointCloud2ConstPtr &laserCloudMsg)
{
    cloudQueueMutex.lock();
    cloudQueue.push(laserCloudMsg);
    cloudQueueMutex.unlock();
    newLaserCloudReceived = true;
}

Both implementations use similar queue-based approaches for handling incoming point cloud messages. LeGO-LOAM adds a flag to indicate new data arrival, potentially improving responsiveness in the main processing loop.

Pros of LIO-SAM

• Integrates LiDAR, IMU, and GPS data for more robust localization and mapping
• Implements loop closure for improved accuracy in large-scale environments
• Offers real-time performance with lower computational requirements

Cons of LIO-SAM

• More complex setup and configuration due to multiple sensor inputs
• Requires careful calibration of sensors for optimal performance
• May struggle in environments with limited GPS coverage

Code Comparison

A-LOAM (scan matching):

void laserCloudCornerLastHandler(const sensor_msgs::PointCloud2ConstPtr& msg) {
    timeLaserCloudCornerLast = msg->header.stamp.toSec();
    laserCloudCornerLast->clear();
    pcl::fromROSMsg(*msg, *laserCloudCornerLast);
    newLaserCloudCornerLast = true;
}

LIO-SAM (IMU integration):

void imuHandler(const sensor_msgs::Imu::ConstPtr& imuMsg) {
    sensor_msgs::Imu thisImu = imuConverter(*imuMsg);
    imuQueOpt.push_back(thisImu);
    imuQueImu.push_back(thisImu);
    imuTime[imuPointerLast] = thisImu.header.stamp.toSec();
    imuPointerLast = (imuPointerLast + 1) % imuQueLength;
}

Pros of open_vins

• More comprehensive visual-inertial odometry (VIO) system with multi-sensor fusion capabilities
• Supports various sensor configurations, including monocular, stereo, and multi-camera setups
• Actively maintained with regular updates and improvements

Cons of open_vins

• Higher complexity and steeper learning curve compared to A-LOAM
• Requires more computational resources due to its comprehensive nature

Code Comparison

A-LOAM (scanRegistration.cpp):

void laserCloudHandler(const sensor_msgs::PointCloud2ConstPtr &laserCloudMsg)
{
    if (!systemInited)
    {
        systemInitCount++;
        if (systemInitCount >= systemDelay)
        {
            systemInited = true;
        }
        return;
    }
    // ... (processing code)
}

open_vins (VioManager.cpp):

void VioManager::feed_measurement_imu(const ov_core::ImuData &message) {
    // Append it to our vector
    imu_data.emplace_back(message);

    // Loop through and delete old measurements
    auto it0 = imu_data.begin();
    while (it0 != imu_data.end() && it0->timestamp < state->_timestamp - params.calib_camimu_dt) {
        it0 = imu_data.erase(it0);
    }
}

The code snippets show different approaches to handling sensor data. A-LOAM focuses on LiDAR data processing, while open_vins demonstrates IMU data management within a more complex VIO system.