The Málaga urban dataset: High-rate stereo and LiDAR in a realistic urban scenario

2.1. Physical characteristics

In order to be able to navigate outdoors in a safe way throughout typical urban scenarios we decided to employ a common Citroen C4 car, shown in Figure 1. All the sensors were installed on a modified roof-rack, designed for the flexible placement of heterogeneous devices. This configuration allowed us to drive through city traffic without restriction.

OPEN IN VIEWER

Fig. 1.

The vehicle employed for collecting the dataset: (a) general view and (b) close-up of the sensors.

Two computers were also installed inside the vehicle to cope with the computational and storage bandwidth requirements. All the electrical power for the computers and sensors was obtained from the vehicle’s own power system.

We recorded data from eight sensors: one stereo camera, five laser scanners, one inertial measurement unit (IMU) and one global positioning system (GPS) receiver.

Figure 2 schematically illustrates the placement of each sensor on the vehicle, with approximate (hand-measured) coordinates shown in Table 2

OPEN IN VIEWER

Fig. 2.

Side and top views, respectively, of the relative positions of sensors on the vehicle’s roof-rack structure. Compare with Figure 1(b). Not to scale.

OPEN IN VIEWER

Table 2.

Summary of the approximate sensor positioning on the vehicle. Refer to Figure 2.

Sensor	x (m)	y (m)	z (m)	yaw (◦)	pitch (◦)	roll (◦)
CAMERA1	0.785	0	0.273	0	−8.2	0
XSensMTi	0.400	0.040	0.000	0	0	0
GPS_DELUO	0.155	0.069	0.004	n/a	n/a	n/a
LASER1 (rear SICK)	−0.023	0	0.097	−180	0	0
LASER2 (front SICK)	0.536	0	0.093	0	0	0
HOKUYO1 (Front)	0.536	0	0.273	0	21.4	0
HOKUYO2 (Right)	0.075	−0.489	0.055	−90	0	−90
HOKUYO3 (Left)	0.075	0.489	0.055	90	0	90

Next we briefly describe the relevant characteristics of each sensor and the reasons for their inclusion in the dataset.

2.1.4. The global positioning system receiver

We also installed a consumer-grade, low-cost GPS receiver on the car, with a two-fold purpose: (i) providing approximate positioning for a better understanding of the whole trajectory traversed in this dataset (see Figure 3), and (ii) offering realistic GPS data for usage in visual SLAM applications aimed at the automotive industry.

OPEN IN VIEWER

Fig. 3.

An overview of the complete trajectory, as reconstructed from GPS data. A zoomable version is available online.

This sensor provides positioning data at 1 Hz during the whole dataset, with the exception of a few unavoidable segments (‘urban canyons’ and dense groves) where the signal was too weak to provide good localization.

Two additional industry-grade GPS receivers were also installed in the vehicle (mmGPS devices from Topcon, the two cylindrical yellow devices in Figure 1), but positioning information was not available from these receivers during the recording of the dataset. However, frames with GPS timing information were collected from both receivers in order to accurately synchronize the local clocks of the two computers. By grabbing satellite timestamps from two identical receivers in both computers we have been able to establish a least-square fit of the mapping between the reference GPS time and the local clocks. More importantly, this mapping provides an accurate way of merging the partial datasets grabbed in each machine during an offline post-processing stage. Interestingly, we found out that not only did the local clocks have an offset (as could be expected) but that they exhibited a small drift (6.06 and 83.33 ms/s, respectively), which has been corrected in the published dataset.

2.2. Software

The vehicle was equipped with sensors of quite different types, each generating data at different rates. Thus, the software intended to record the data logs must be capable of dealing with asynchronous streams from the sensors. For this purpose, we employed the data logger application rawlog-grabber, as we also did for previous datasets (Blanco et al., 2009).

This program launches one thread for each individual sensor. Then, each thread splits the sensory data into their corresponding natural discrete pieces (called observations), e.g. a complete 2D scan for laser scanners, and marks them with timestamps. Since our system does not run on a real-time OS, we had to ensure that no observation was lost, by creating a first in first out (FIFO) queue for each thread, then merging all of their outputs into a thread-safe timestamp-sorted queue, which was periodically pushed to a binary rawlog file. We chose binary log files for their bandwidth efficiency in contrast to other pure-text formats. Afterwards, we post-processed the binary logs to generate plain text logs for the convenience of readers.

Collecting large images (1,024 × 768) at real-time without dropping frames presented an additional challenge, because hard-disk bandwidth is not enough for saving raw images, while lossy compression solves the issue but introduces a high computational burden. Our approach consisted of parallelizing the latter task by creating additional threads with the sole purpose of compressing images into a high-quality format (JPEG format, quality = 95).

3.1. Description

The dataset was recorded as a single sequence during a car trip throughout different urban areas of Málaga, with a total duration of ~93 min. An overlaid impression of the GPS-reconstructed path over a map of the city is provided in Figure 3.

Observations from all sensors were recorded at their maximum nominal rates. These values, along with the actual average rates obtained from the logged stream of data, are shown in Table 3. The similarity of actual and nominal rates means that only a tiny fraction of sensory data was dropped for most sensors (mostly due to corrupt frames for communication errors), with the worst case being the sensor LASER2 (front SICK laser) for which 1.9% of all frames was lost. Overall, 2.2 million individual observations were collected.

OPEN IN VIEWER

Table 3.

Summary of the grabbed data from each sensor. The actual rates shown here are the average values obtained as the ratio count: duration.

Sensor label	Count	Duration (s)	Actual rate (Hz)	Nominal rate (Hz)
CAMERA1	113,082	5,654.6	19.998	20
GPS_DELUO	11,244	5,653.0	1.989	1
HOKUYO1	225,416	5,654.62	39.864	40
HOKUYO2	225,631	5,654.62	39.902	40
HOKUYO3	225,510	5,654.62	39.880	40
LASER1	398,531	5,315.58	74.974	75
LASER2	404,487	5,498.11	73.568	75
XSensMTi	549,816	5,498.15	100.000	100

Regarding the trajectory followed during the recording, we can split the dataset into the following segments or epochs (within parentheses, the starting and end points measured in minutes since the start):

As an additional tool to help the interested reader to pick relevant segments from the dataset we created a video index (see Figure 4), available online. ² Apart from the camera images, the video shows a 3D point-cloud reconstruction of the environment from the vertical laser scanners and GPS data as a gross estimate of the ground truth path. Some snapshots of the obtained scenarios can be also seen in Figure 5.

OPEN IN VIEWER

Fig. 4.

A view of the dataset video index, which simultaneously displays: (top-left) raw video frames, (bottom-left) the current location of the vehicle over the city map and (right) the local 3D point-cloud from the laser scanners.

OPEN IN VIEWER

Fig. 5.

Three sample screenshots from the dataset: (left) 3D reconstructions from vertical laser scanners and GPS-only information, (right) images from the stereo camera in the same places.

In order to make working with the dataset easier, it was further divided into 15 smaller sequences or extracts, illustrated in Figure 6. A video is also available online for each individual sequence, such that they can be easily inspected. Next, we enumerate the length in seconds of each extract and provide a brief description of its contents:

OPEN IN VIEWER

Fig. 6.

Summary of the 15 dataset extracts available for download. For each segment, the vehicle path is shown together with aerial urban images for reference. Refer to the online material for interactive maps.

Although all sensory data are provided in plain-text format, it is worth mentioning that two ready-to-use applications (named RawLogViewer and rawlog-edit) are provided to inspect, filter or split binary log files. These programs are already shipped within modern Debian and Ubuntu GNU/Linux distributions as part of the package mrpt-apps. Example C++ source code is also available online for readers interested in parsing binary logs.

3.2. Challenges

We found that a particularly challenging problem during the recording of outdoor images was the appearance of vertical smears caused by direct sun exposure. After several attempts on different days we obtained, on a cloudy day, the present dataset which exhibits a minor occurrence of such smears. Another challenging aspect of the images, from the point of view of computer vision, was the dynamic gain control of the camera which may introduce hurdles for feature-tracking algorithms. However, we believe that these challenges are intrinsic and unavoidable for any real-world problem where cameras are to be placed on vehicles for navigation in uncontrolled, outdoor scenarios. In order to allow researchers to easily compare diverse robust techniques against this kind of problem, we released two short dataset extracts (numbered #14 and #15) with direct sun exposure.