Other

技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

深度分析:HKUST-Aerial-Robotics/GVINS-Dataset

项目背景与痛点

在无人机和无人驾驶车辆领域,数据集是至关重要的资源。尤其是在视觉、惯性以及GNSS传感器融合的研究应用中,高质量的数据集更是不可或缺。HKUST-Aerial-Robotics实验室推出的GVINS-Dataset项目,正是为了解决这些痛点。该数据集包含了同步的视觉、惯性、GNSS原始测量数据,这些数据对于导航系统的开发和测试至关重要,使得研究人员能够更深入地分析传感器融合的算法效果以及系统的性能表现。

核心技术揭秘

GVINS-Dataset项目的核心在于其数据的同步采集与处理。数据集中的每个时刻都记录了对应的视觉、惯性以及GNSS测量结果,借以完整保留各种传感器行为。

为了提供一个清晰的技术架构分析,我们将使用 Mermaid 制作一张数据流图。

graph TD A[数据采集] --> B[同步采样] B --> C[数据存储] C --> D[数据预处理] D --> E[格式化输出] E --> F[数据发布]

从上图可见,数据流的过程经过多层的处理和逻辑构建,首先是同步采集各个传感器的数据,然后进行数据存储,紧接着是对这些数据进行预处理,最终转化为适合后续使用和研究的格式,并发布。

功能亮点与差异

相较于其他噪声大或精度低的数据集,GVINS-Dataset的亮点在于全方位、高质量的数据捕获,使研究者能够轻松访问与处理来自不同传感器的多种信息线索,并且保证这些数据的同步性。

其细节设计上,所有节点都进行了精准的同步与时态矫正,确保数据的一致性和准确性。

应用场景与落地建议

在开发或测试环境下使用GVINS-Dataset,应注意校准和验证流程。建议其适用于多传感器融合应用的研发,尤其是那些需要处理复杂环境感知任务的设备,例如自主导航、图像配准、基于视觉的轨迹估计等场合。此外,项目应考虑到实时运行的计算资源要求,确保数据处理能力能够满足不同业务场景下的需求。

综合评价

GVINS-Dataset是一个备受关注的数据集,其在同步采集多种传感器数据上的实现能力非常卓越,给从事传感器融合研究的开发者们提供了宝贵的资源。然而,它同样存在一些不足,比如数据规模可能无法完全覆盖所有的应用场景需求,需要根据实际项目需求进行相应的处理和扩展。总体来看,GVINS-Dataset是一个在多传感器数据集成研究方面的强大资源。

关于

GitHub 原始描述(英文)

A dataset containing synchronized visual, inertial and GNSS raw measurements.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
385
价值分
176
活跃状态
活跃

语言占比

C++
CMake

贡献者

README

GVINS-Dataset

Author/Maintainer: CAO Shaozu (shaozu.cao AT gmail.com), LU Xiuyuan (xluaj AT connect.ust.hk), SHEN Shaojie (eeshaojie AT ust.hk)

This repository hosts dataset collected during the development of GVINS. The dataset contains GNSS raw measurement, visual and inertial data which are necessary for GNSS-Visual-Inertial fusion algorithm.

Updates:

  • Aug 29, 2026: The dataset is now hosted on Hugging Face; the previous OneDrive link has been removed (as it is no longer valid).

1. Sensor Suit

sensorsuit

1.1. VI-Sensor

The visual and inertial data are collected using a VI-Sensor. The VI-Sensor has two Aptina MT9V034 image sensors, which form a stereo camera together, and a Analog Devices ADIS 16448 IMU. The image and inertial data from the VI-Sensor are well synchronized by hardware design. A detailed spec sheet of this sensor can be found here. The camera and IMU parameters can be found in GVINS-Dataset/data/visensor_parameters/.

1.2. u-blox ZED-F9P Receiver

We use u-blox ZED-F9P to collect GNSS raw measurements and ground truth location. The ZED-F9P owns an internal RTK engine which is capable to provide receiver’s location at an accuracy of 1cm in open area. To obtain the RTK solution, a real-time RTCM stream from a 3km away GNSS observation station is fed to the receiver. The GNSS antenna in our platform is a Tallysman’s TW3882.

2. Synchronization

The time system between the VI-Sensor and the GNSS receiver is synchronized via Pluse Per Second (PPS) signal. The synchronization process is illustrated in the figure below:

sync_diagram

  1. The GNSS receiver reports the time information of next PPS signal. In our system the reporting frequency is set to 1Hz.
  2. The PPS signal from the GNSS receiver is used to trigger the external interrupt of VI-Sensor. In our system the frequency of PPS is set to 0.2 Hz.
  3. When VI-Sensor is interrupted by the PPS signal, it reports its local time to the host computer.

In this way the host computer knows both the global and local timestamps of the PPS signal so these two time systems get aligned together.

3. Dataset Details

The dataset is released in the form of rosbag and currently there are two rosbags available:

name duration size link
sports_field 25min 22.0GB Hugging Face
complex_environment 32min 17.3GB Hugging Face
urban_driving 41min 35.9GB Hugging Face

The data items within the rosbag are listed below:

topic type frequency description
/cam0/image_raw sensor_msgs/Image 20Hz right camera
/cam1/image_raw sensor_msgs/Image 20Hz left camera
/imu0 sensor_msgs/Imu 200Hz IMU
/external_trigger gvins/LocalSensorExternalTrigger - publish when VI-Sensor is trigger. definition
/ublox_driver/receiver_lla sensor_msgs/NavSatFix 10Hz Receiver’s GNSS solution (brief).
/ublox_driver/receiver_pvt gnss_comm/GnssPVTSolnMsg 10Hz Receiver’s GNSS solution (verbose). definition
/ublox_driver/range_meas gnss_comm/GnssMeasMsg 10Hz GNSS raw measurement. definition
/ublox_driver/ephem gnss_comm/GnssEphemMsg - The broadcast ephemeris of GPS, Galileo and BeiDou. definition
/ublox_driver/glo_ephem gnss_comm/GnssGloEphemMsg - The broadcast ephemeris of GLONASS. definition
/ublox_driver/iono_params gnss_comm/StampedFloat64Array - The broadcast ionospheric parameters. definition
/ublox_driver/time_pulse_info gnss_comm/GnssTimePulseInfoMsg 1Hz The time information of next PPS signal. definition.

4. Toolkit

The toolkit provided in this package requires gnss_comm library.

4.1. Convert GNSS raw measurement to RINEX File

Many GNSS softwares like RTKLIB accept RINEX file as the input. To convert the GNSS raw measurements in the rosbag to the corresponding RINEX file, firstly clone this repo to your catkin workspace and set INPUT_BAG_FILEPATH and OUTPUT_RINEX_FILEPATH in toolkit/src/bag2rinex.cpp. Then build and run the toolkit with:

cd ~/catkin_ws/
catkin_make
source devel/setup.bash
rosrun gvins_dataset_toolkit bag2rinex

The observation RINEX file should be generated after a while. The corresponding GNSS ephemeris RINEX file can be found in GVINS-Dataset/data/ephemeris_rinex/.

4.2 Save RTK solution to csv file

To extract the RTK solution and status to a local csv file, firstly set INPUT_BAG_FILEPATH and OUTPUT_RTK_FILEPATH in toolkit/src/bag2rtk_solution.cpp. Then build and run the toolkit with:

cd ~/catkin_ws/
catkin_make
source devel/setup.bash
rosrun gvins_dataset_toolkit bag2rtk_solution

Each record in the generated csv file is in the form of:

gnss_ts_ns, ecef_px, ecef_py, ecef_pz, enu_vx, enu_vy, enu_vz, fix_type, valid_fix, diff_soln, carr_soln

, with each item described in the following:

name description
gnss_ts_ns GNSS time of the navigation epoch (expressed as Unix timestamp in ns)
ecef_p* The x, y, z component of the position in ECEF frame
enu_v* The x, y, z component of the velocity in ENU frame
fix_type GNSS fix type (0=no fix, 1=dead reckoning only, 2=2D-fix, 3=3D-fix, 4=GNSS+dead reckoning combined, 5=time only fix)
valid_fix if fix valid (1=valid fix)
diff_soln if differential correction were applied (1=applied)
carr_soln carrier phase range solution status (0=no carrier phase, 1=float, 2=fix)

5. License

The dataset is released under CC-BY-NC-SA-4.0 license.

评论

暂无评论