Convert Figma logo to code with AI

ethz-asl logorovio

No description available

1,123
506
1,123
79
View on GitHub

Top Related Projects

HKUST-Aerial-Robotics's avatar

VINS-Mono

4,926

A Robust and Versatile Monocular Visual-Inertial State Estimator

UZ-SLAMLab's avatar

ORB_SLAM3

6,394

ORB-SLAM3: An Accurate Open-Source Library for Visual, Visual-Inertial and Multi-Map SLAM

raulmur's avatar

ORB_SLAM2

9,286

Real-Time SLAM for Monocular, Stereo and RGB-D Cameras, with Loop Detection and Relocalization Capabilities

JakobEngel's avatar

dso

2,271

Direct Sparse Odometry

uzh-rpg's avatar

rpg_svo

2,085

Semi-direct Visual Odometry

Quick Overview

ROVIO (Robust Visual Inertial Odometry) is an open-source visual-inertial odometry framework developed by the Autonomous Systems Lab at ETH Zurich. It combines visual and inertial measurements to estimate the pose of a robot or device in real-time, making it suitable for various robotics and augmented reality applications.

Pros

  • Robust performance in challenging environments, including fast motions and low-texture scenes
  • Efficient implementation, suitable for real-time applications on embedded systems
  • Supports both monocular and stereo camera setups
  • Extensive documentation and active community support

Cons

  • Steep learning curve for users unfamiliar with visual-inertial odometry concepts
  • Requires careful calibration and parameter tuning for optimal performance
  • Limited support for integrating with other sensor types (e.g., LiDAR, GPS)
  • May struggle in environments with extreme lighting conditions or highly dynamic scenes

Code Examples

  1. Initializing ROVIO:
#include <rovio/RovioNode.hpp>

int main(int argc, char** argv) {
    ros::init(argc, argv, "rovio");
    ros::NodeHandle nh;
    rovio::RovioNode rovioNode(nh);
    ros::spin();
    return 0;
}
  1. Subscribing to sensor topics:
rovioNode.subImu_ = nh.subscribe("imu0", 1000, &rovio::RovioNode::imuCallback, &rovioNode);
rovioNode.subImg0_ = nh.subscribe("cam0/image_raw", 1000, &rovio::RovioNode::imgCallback0, &rovioNode);
  1. Accessing estimated pose:
Eigen::Vector3d position = rovioNode.filter_->safe_.state_.WrWM();
Eigen::Quaterniond orientation = rovioNode.filter_->safe_.state_.qWM();

Getting Started

  1. Clone the repository:

    git clone https://github.com/ethz-asl/rovio.git

  2. Install dependencies:

    sudo apt-get install ros-<distro>-opencv3 ros-<distro>-eigen-conversions

  3. Build the project:

    catkin build rovio

  4. Run ROVIO with a sample dataset:

    roslaunch rovio rovio_node.launch
rosbag play <path_to_dataset>.bag

Competitor Comparisons

HKUST-Aerial-Robotics logo

VINS-Mono

4,926

A Robust and Versatile Monocular Visual-Inertial State Estimator

Pros of VINS-Mono

  • Supports loop closure for improved accuracy and drift reduction
  • Provides a more comprehensive visual-inertial odometry solution
  • Includes a sliding window optimization approach for better estimation

Cons of VINS-Mono

  • Higher computational complexity compared to ROVIO
  • May require more tuning and parameter adjustment for optimal performance

Code Comparison

VINS-Mono (C++):

void FeatureManager::triangulate(Vector3d Ps[], Vector3d tic[], Matrix3d ric[])
{
    for (auto &it_per_id : feature)
    {
        it_per_id.used_num = it_per_id.feature_per_frame.size();
        if (!(it_per_id.used_num >= 2 && it_per_id.start_frame < WINDOW_SIZE - 2))
            continue;
        // ... (triangulation logic)
    }
}

ROVIO (C++):

void FeatureManager::triangulateFeature(const FeatureCoordinates& c1, const FeatureCoordinates& c2, const V3D& BrBC1, const V3D& BrBC2, const QPD& qCB1, const QPD& qCB2, V3D& BrBM) const
{
    V3D d1 = qCB1.rotate(c1.get_nor().getVec());
    V3D d2 = qCB2.rotate(c2.get_nor().getVec());
    // ... (triangulation logic)
}

Both repositories use C++ and implement feature triangulation, but VINS-Mono's approach appears more integrated with its sliding window optimization, while ROVIO's implementation is more focused on individual feature triangulation.

UZ-SLAMLab logo

ORB_SLAM3

6,394

ORB-SLAM3: An Accurate Open-Source Library for Visual, Visual-Inertial and Multi-Map SLAM

Pros of ORB_SLAM3

  • More comprehensive SLAM system, supporting monocular, stereo, and RGB-D cameras
  • Includes loop closing and relocalization capabilities
  • Better performance in large-scale environments

Cons of ORB_SLAM3

  • Higher computational requirements
  • More complex setup and configuration
  • Less suitable for resource-constrained platforms

Code Comparison

ROVIO (C++):

rovio::RovioFilter<rovio::FilterState> filter;
filter.resetToInitialState(initState);
filter.performPrediction(imuMeasurement, dt);
filter.performUpdate(imageMeasurement);

ORB_SLAM3 (C++):

ORB_SLAM3::System SLAM(vocabPath, settingsPath, ORB_SLAM3::System::MONOCULAR);
cv::Mat pose = SLAM.TrackMonocular(image, timestamp);
SLAM.Shutdown();

Both repositories use C++ and are designed for visual odometry and SLAM applications. ROVIO focuses on efficient visual-inertial odometry, while ORB_SLAM3 offers a more comprehensive SLAM solution with additional features like loop closing. ROVIO is better suited for resource-constrained platforms, while ORB_SLAM3 excels in larger environments but requires more computational power.

raulmur logo

ORB_SLAM2

9,286

Real-Time SLAM for Monocular, Stereo and RGB-D Cameras, with Loop Detection and Relocalization Capabilities

Pros of ORB_SLAM2

  • More accurate localization and mapping in large-scale environments
  • Supports loop closure for improved map consistency
  • Capable of relocalization after tracking loss

Cons of ORB_SLAM2

  • Higher computational requirements
  • Less suitable for resource-constrained platforms
  • May struggle in environments with limited visual features

Code Comparison

ORB_SLAM2 (feature extraction):

void Frame::ExtractORB(int flag, const cv::Mat &im)
{
    (*mpORBextractorLeft)(im,cv::Mat(),mvKeys,mDescriptors);
}

ROVIO (feature extraction):

void MultilevelPatchFeature::extractMultilevelPatch(const cv::Mat& img, const cv::Point2f& pos){
  for(unsigned int l=0;l<nLevels_;l++){
    patches_[l].extractPatch(img,pos,l);
  }
}

ORB_SLAM2 focuses on ORB feature extraction, while ROVIO uses a multi-level patch approach for feature extraction. This difference reflects their distinct approaches to visual odometry and SLAM.

JakobEngel logo

dso

2,271

Direct Sparse Odometry

Pros of DSO

  • Direct method approach, which can work in low-texture environments
  • More accurate in challenging scenarios with rapid motion or changing lighting
  • Computationally efficient, suitable for real-time applications on mobile devices

Cons of DSO

  • Requires careful parameter tuning for optimal performance
  • May struggle with pure rotation motions
  • Less robust to dynamic objects in the scene compared to feature-based methods

Code Comparison

DSO uses a direct photometric error minimization approach:

void CoarseTracker::makeCoarseDepthL0(std::vector<dso::FrameHessian*> frameHessians)
{
    // ... (code for coarse depth estimation)
}

ROVIO, on the other hand, uses an indirect feature-based approach:

void rovio::RovioNode::imgCallback(const sensor_msgs::ImageConstPtr & img)
{
    // ... (code for feature extraction and tracking)
}

Both repositories implement visual odometry systems, but they use fundamentally different approaches. DSO operates directly on image intensities, while ROVIO relies on extracted features for pose estimation.

uzh-rpg logo

rpg_svo

2,085

Semi-direct Visual Odometry

Pros of rpg_svo

  • Faster processing speed, suitable for real-time applications
  • More robust in environments with rapid camera motion
  • Lighter computational load, making it ideal for resource-constrained systems

Cons of rpg_svo

  • Less accurate in environments with few visual features
  • May struggle with loop closure in larger environments
  • Limited to monocular vision, lacking depth information from stereo setups

Code Comparison

rpg_svo:

FrameHandlerMono::FrameHandlerMono(vk::AbstractCamera* cam) :
  FrameHandlerBase(),
  cam_(cam),
  reprojector_(cam_, map_),
  depth_filter_(NULL)
{
  initialize();
}

rovio:

ROVIO::ROVIO(const std::string& configFile){
  readConfigFile(configFile);
  init();
}

rpg_svo focuses on monocular vision processing, while rovio is designed for visual-inertial odometry, integrating both camera and IMU data. The code snippets show their different initialization approaches, with rpg_svo's constructor taking a camera object and rovio's reading from a configuration file.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

README

This repository contains the ROVIO (Robust Visual Inertial Odometry) framework. The code is open-source (BSD License). Please remember that it is strongly coupled to on-going research and thus some parts are not fully mature yet. Furthermore, the code will also be subject to changes in the future which could include greater re-factoring of some parts.

Video: https://youtu.be/ZMAISVy-6ao

Papers:

Please also have a look at the wiki: https://github.com/ethz-asl/rovio/wiki

Install without opengl scene

Dependencies:

#!command

catkin build rovio --cmake-args -DCMAKE_BUILD_TYPE=Release

Install with opengl scene

Additional dependencies: opengl, glut, glew (sudo apt-get install freeglut3-dev, sudo apt-get install libglew-dev)

#!command

catkin build rovio --cmake-args -DCMAKE_BUILD_TYPE=Release -DMAKE_SCENE=ON

Euroc Datasets

The rovio_node.launch file loads parameters such that ROVIO runs properly on the Euroc datasets. The datasets are available under: http://projects.asl.ethz.ch/datasets/doku.php?id=kmavvisualinertialdatasets

Further notes

  • Camera matrix and distortion parameters should be provided by a yaml file or loaded through rosparam
  • The cfg/rovio.info provides most parameters for rovio. The camera extrinsics qCM (quaternion from IMU to camera frame, Hamilton-convention) and MrMC (Translation between IMU and Camera expressed in the IMU frame) should also be set there. They are being estimated during runtime so only a rough guess should be sufficient.
  • Especially for application with little motion fixing the IMU-camera extrinsics can be beneficial. This can be done by setting the parameter doVECalibration to false. Please be carefull that the overall robustness and accuracy can be very sensitive to bad extrinsic calibrations.