Introduction
We provide a dataset for laser-odometry based on a single Velodyne HDL-32 sensor.
The sensor contains a built-in IMU.
What sets us apart from other datasets is that
- We provide laser data with timestamps associated with each individual measurement (i.e. point) obtained from the sensor.
- We provide so-called checkpoints, i.e. ground truth relative poses between individual laserscans. Checkpoints allow determining the amount of drift that has accumulated.
We record data from the sensor by simply capturing the raw network packets to a .pcap file. After capturing, we present the data to a customized ROS driver, that converts the laser and IMU data to standard ROS messages. These messages are finally processed by a simple ROS node that dumps all messages to a text file.
Our setup for a head-mounted Velodyne HDL-32 sensor. This configuration was used to record sequences `campus_run_1` and `campus_run_2`.
Combining multiple overlapping sequences like `campus_run_1`, `campus_run_2` and `campus_drive` allows for a reconstruction of our campus.
Details
Coordinate System
The following image shows the coordinate system of the Velodyne HDL32-E sensor.
Red, green and blue arrows correspond to the x, y and z axis of the sensor. The black line connected to the cylinder of the Velodyne shows the placement of the cable. The geometric placement of the three gyro+dual accelerometer pairs is unknown and has been ignored in the processing of the data.
For technical reasons, the primary direction of movements is the +y direction in some datasets, and the +x direction in others.
Data Format
The heart of the dataset is a text-based file called log.txt. It contains events in the order of occurrence.
Each line contains one event. There are three possible events:
VEL_IMU
This event occurs when a new set of IMU measurements was received from the Velodyne IMU. The data format is:
VEL_IMU <timestamp> <omega_x> <omega_y> <omega_z> <a_x> <a_y> <a_z>
where
timestampis the time of the event in microseconds (1 second equals 1000 * 1000 microseconds)omega_x,omega_y,omega_zare the gyroscope measurements along the three axes. They are given in rad/s.a_x,a_y,a_zare the accelerometer measurements, given in m/s^2.
Example:
VEL_IMU 2984260 -0.23181 0.194312 0.0784065 0.478957 -0.131713 9.71684
—Note—
The Velodyne HDL 32-E sensor contains three separate chips that contain a single-axis gyro and a two-axis accelerometer each. The gyro measurements can be used the way they are. However, there are two accelerometers covering each axis. As a ‘fix’, we average these two accelerometers. We obtain our measurements from the raw sensor data as follows:
omega_x = chip0.gyro;
omega_y = chip1.gyro;
omega_z = chip2.gyro;
a_x = (-chip1.accel.y - chip2.accel.y) / 2;
a_y = ( chip0.accel.y - chip2.accel.x) / 2;
a_z = ( chip0.accel.x + chip1.accel.x) / 2;
See here for details.
VEL_START and VEL_END
These events occur when the Velodyne has either started or ended one revolution. Every VEL_START event has a corresponding VEL_END event. Revolutions start and end in the opposite direction of movement.
The data format is:
VEL_START <timestamp> <filename>
where
timestampis the time of the event in microseconds (1 second equals 1000 * 1000 microseconds). Note that for VEL_START, the timestamp corresponds to the first point within the revolution. For VEL_END, it corresponds to the last point within the revolution. For this reason, there is typically a very short time between revolutions.filenamerefers to a binary file containing all points during the specified revolution.
Example:
VEL_START 2129452 vel_000000002129452_000000002224938.bin
...
VEL_END 2224938 vel_000000002129452_000000002224938.bin
The .bin files are stored in a tighly-packed binary format. The format is
<num_points : uint32> <point_1 : Point> <point_2 : Point> ... <point_{num_points-1} : Point>
Where each Point is an instance of the following datastructure:
<x : float> <y : float> <z : float> <intensity : float> <ring : uint16> <timestamp : int64>
Checkpoints
In order to evaluate the correctness and measure the accuracy of the applied odometry and mapping algorithms, a ground truth for the recorded dataset is needed. In order to cope with the inaccuracy of a GPS sensor inside of buildings, we decided to apply a different approach consistently on all of our datasets.
All our datasets contain at least one loop between the starting- and the end position.
We introduce the concept of checkpoints in our datasets. A checkpoint is a point at which a loop in the data could be closed, making it possible to determine the relative pose between the two scans involved. It represents the amount of drift that has accumulated over the course of the loop.
For our datasets, checkpoints have been obtained manually using a specialized tool to perform and verify the registration.
We manually iterate along the trajectory obtained from an initial registration of the pointclouds. Each step on the trajectory is associated with a distinct pointcloud. We then manually select two scans, identified by their unique timestamp, one of them being recorded in the beginning of the loop, the second one being recorded at roughly the same world position as the first one after completing the loop.
Using a specialized ICP algorithm taking into consideration the entirety of the scan points contained in the selected two pointclouds, we are able to determine the relative pose between the two scans, which is then considered as a checkpoint.
Those checkpoints can be used as a ground truth to our different sequences. In the style of the KITTI evaluation, the translational- and rotational drift per meter can be calculated by averaging over the errors divided by the loop lengths.
The determined checkpoints are contained in the checkpoints_<SEQUENCE>.json files, where <SEQUENCE> is the name of the desired dataset. A single checkpoint is organized in the following structure :
[
{
"start_timestamp_a": 49082083,
"end_timestamp_a": 49183265,
"start_timestamp_b": 209266977
"end_timestamp_b": 209363734,
"pose": [
-0.15407261907271877,
-0.09721974123330189,
0.02685432652092385,
0.9947879046851292,
0.012542354730202404,
0.04128954721524042,
0.09238445389107608
]
}
]
end_timestamp_a and end_timestamp_b represent the respective unique timestamp associated with the pointcloud a and b. The end keyword indicates that the timestamp associated with the pointcloud was saved after the Velodyne HDL-32 sensor completed a revolution, the start keyword indicates that the timestamp was taken with the beginning of a new revolution.
The pose keyword represents the determined ground truth pose as a 7D vector. This vector consists of three translational components and four rotational components, which represent a unit quaternion in the order w, x, y, z.
Sequences
Overlay of our trajectories onto a Google Maps screenshot. `campus_run_2` is represented in a light blue colour, `field` is represented in red and `campus_drive` is shown in yellow.
campus_drive
This dataset consists of a loop recorded by our Velodyne HDL-32 sensor, mounted on top of a car. The car was driven around campus, a mixture between trees and hard edges originating from buildings are prominent. Especially the different trees and shrubs can result in noisy and hard-to-match features. The dataset contains one loop/ checkpoint, namely the starting-/end-position.
field
This dataset was recorded by our Velodyne HDL-32 sensor, mounted on top of a car similar to the well-known KITTI Dataset. This trajectory contains one loop, however, several checkpoints have been generated. The challenging part in this scan is the field around which the loop is driven. This field on the left side of the car barely contains any distinguishable features. On the right, several different environments are seen, alternating between cars, hedges and fences.
campus_run_1
Screenshot of a rendering from a sector of the `campus_run_1` dataset. This trajectory was too complex to be displayed in a meaningful way in the above image.
This dataset is our longest dataset, recorded by a head-mounted Velodyne HDL-32 sensor, containing multiple loops. The challenges on this dataset are contained in the change of environment and altitude during the scan. Starting on the third floor inside a building, we descend a set of staircases, exit the building in order to roam on the outside and finally ascend back to the third floor in order to close the main loop. While roaming on the outside, we cross our path multiple times on purpose in order to include several loops in the trajectory. The checkpoints, which are used as ground truth, coincide with the contained loops.
The main challenge consists in maintaining a sharp map on the sudden change from narrow hallways and staircases to a wider and more noisy environment on the outside.
campus_run_2
This trajecory, similar to campus_run_1, was recorded with a head-mounted Velodyne HDL-32 sensor as well, however only one loop/ckeckpont is present, namely the starting-/end-position. Again, as both inside and outside portions are recorded, the challenge consists in maintaining a good map quality during those transitions. The head movements are much more erractic for this scan.
Authors
The dataset, format and software are being provided by
Frank Neuhaus, Tilmann Koss, Robert Kohnen and Dietrich Paulus
Active Vision Group, University of Koblenz-Landau, ICV
Contact: Frank Neuhaus
When using the dataset, please cite our paper:
MC2SLAM: Real-Time Inertial Lidar Odometry using Two-Scan Motion Compensation
Frank Neuhaus, Tilmann Koss, Robert Kohnen and Dietrich Paulus
Changelog
2018-09-20 – Initial release.
License
All datasets and benchmarks on this page are copyright by us and published under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. This means that you must attribute the work in the manner specified by the authors, you may not use this work for commercial purposes and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same license.