IPDS: The Institut Pascal multisensors Data Sets for mobile robotics

Data were acquired using the Effibox middleware from EFFIDENCE compagny. Imagery is recorded in loseless .pgm/.ppm for the cameras. Laser, GPS, inertial measurements and odometry data are provided in human-readable plain text. All data are timestamps from the beginning of the acquisition and we have supposed that both computers are synchronized in time. $AcquisitionTimeUTC=\underbrace{Rtime+latency}_{\text{Acquisition time (relative reference)}} + starting\_time$

Logs format

The data of each interface are saved in a folder called ID_INTERFACE (one interface by visual sensor, range sensor and GPS, one interface for the CAN bus where data from the odometry, accelerometer and gyrometer are available). Show more details

List of ID_INTERFACE:

Sensor	Alias	ID_INTERFACE
Visual sensors
Forward left camera	f-l-cam	Bus_InterfaceCamera_2672909685359666
Forward right camera	f-r-cam	Bus_InterfaceCamera_2672909685359667
Backward camera	b-cam	Bus_InterfaceCamera_2672909685359670
Forward middle camera	f-m-cam	Bus_InterfaceCamera_2892819404705840
Catadioptric camera	cata-cam	Bus_InterfaceCamera_13602058368439990
Fisheye camera	fe-cam	Bus_InterfaceCamera_13602058368474999
Webcam	web-cam	Bus_InterfaceCamera__dev_video0
2D Range sensors
Horizontal laser	hz-laser	Bus_InterfaceRangefinder_172_27_30_21_2112
Inclined laser	incl-laser	Bus_InterfaceRangefinder_172_27_30_31_2112
GPS sensors
RTK GPS	rtk-gps	Bus_InterfaceGps__dev_ttyM0
Low-cost GPS	lc-gps	Bus_InterfaceGps__dev_ttyACM0
Proprioceptive sensors
		Bus_InterfaceCan_can0

We also provide other data that have been logged. For instance, they have been obtained by fusing data from multiple sensors (dead-reckoned pose using motor odometry and steering angle data ...).
Visual sensors - Range sensors - GPS sensors - Proprioceptive sensors - Other data

VISUAL SENSORS

Images and timestamp

The file ID_INTERFACE.dates contains data about the acquisition timestamp while the data of i^th image is saved in the file ID_INTERFACE-numextension.

**Log format for visual sensors**
line	ID_INTERFACE.dates				Associated files
#1 (header)	Version
	Rtime	Rtime+latency	latency	→	ID_INTERFACE-num.extension

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
latency is the camera latency, expressed in microseconds
the image number num is the line number plus one, with 10 digits length
the file extension extension is pgm (case of the firewire camera when images are in gray-level) or ppm (case of the color cameras)

Show example

Sample for camera of id ID_INTERFACE=Bus_InterfaceCamera_2672909685359666 (extension=pgm):

	Bus_InterfaceCamera_2672909685359666.dates				Associated files
	Version 1 121558 121558 0 255049 255049 0 388331 388331 0			→	Bus_InterfaceCamera_2672909685359666-0000000001.pgm Bus_InterfaceCamera_2672909685359666-0000000002.pgm Bus_InterfaceCamera_2672909685359666-0000000003.pgm

Bus_...001.pgm	Bus_...002.pgm	Bus_...003.pgm

For the ease of transfer and compact storage, the sequences are available as .mpg video files (in lossless video compression). The procedure to extract image files is described in this page.

RANGE SENSORS

Range sensor impacts and timestamp

The file ID_INTERFACE.dates contains data about the acquisition timestamp while the data of i^th scan is saved in the file(s) ID_INTERFACE-num-numlay.txt.

**Log format for range sensors**
line	ID_INTERFACE.dates		Associated files
#1 (header)	Version XXX
	Rtime	→	ID_INTERFACE-num-numlay.txt

line	ID_INTERFACE-num-numlay.txt
#1 (header)	numimpacts
	angle	distance

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
numlay is the number of the layer. LMS151 sensors have only one layer.
numimpacts is the number of impacts
angle is the angle of the scan, expressed in radians
distance is the distance to the impact, expressed in meters. A distance of zero means that there is no impact in the range of distance of the sensor.

Show example

Sample for range sensor of id ID_INTERFACE=Bus_InterfaceRangefinder_172_27_30_21_2112 (a single layer numlay=0):

	Bus_InterfaceRangefinder_172_27_30_21_2112.dates				Associated files
	Version XXX 191 193478 213493			→	Bus_InterfaceRangefinder_172_27_30_21_2112-1-0.txt Bus_InterfaceRangefinder_172_27_30_21_2112-2-0.txt Bus_InterfaceRangefinder_172_27_30_21_2112-3-0.txt

Bus_...-1-0.txt	Bus_...-2-0.txt	Bus_...-3-0.txt
541 -0.785398 0.135 -0.776672 0.115 -0.767945 0.113 -0.759218 0.092	541 -0.785398 0.14 -0.776672 0.126 -0.767945 0.112 -0.759218 0.113	541 -0.785398 0.115 -0.776672 0.127 -0.767945 0.123 -0.759218 0.107

GPS sensors

3D location and accuracy data

These data are provided by the essential fix data from GGA sentence (refer to http://www.gpsinformation.org/dale/nmea.htm#GGA). These data have been processed to give a file (ID_INTERFACE_GGA_all.txt) which contains the relevant information for most of the applications.

**Log format for GPS sensors**
line	ID_INTERFACE_GGA_all.txt
	Rtime	lat_l2e	lng_l2e	alt_l2e	lat_wgs	lng_wgs	alt_wgs	nb_sat	utc_time	fix_quality	HDOP	age_corr_diff

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
Two coordinates are used for GPS positions: WGS84 (_wgs) and Lambert2IIe (_l2e). lat and lng are the latitude and longitude, expressed in radians for WGS84 coordinates and in meters for Lambert2IIe coordinates. alt is the sum of the altitude above mean sea level (ellipsoidal height) and the height of geoid above ellipsoid, expressed in meters.
In our experiments, the height of geoid (mean sea level) above WGS84 ellipsoid is equal to 50.090 for the RTK-GPS and 47.4 for the UBlox.
nb_sat is the number of satellites being tracked
utc_time is the UTC time when data is taken, expressed in the format YYYYMMDD (as in the GGA sentence).
fix_quality is the fix quality (2 = DGPS fix for the UBlox and 4 = Real Time Kinematic for the RTK-GPS)
HDOP is the horizontal dilution of position
age_corr_diff is the time in seconds since last DGPS update

Show example

Sample for GPS sensor of id ID_INTERFACE=Bus_InterfaceGps__dev_ttyACM0:

	Bus_InterfaceGps__dev_ttyACM0_GGA_all.txt
	476121 660168.799340458 2084722.75496854 460.600012207031 0.798665417515059 0.0542784685555518 460.600012207031 8 32322 2 0.980000019073486 -1 1475353 660168.786374253 2084722.75484107 460.600012207031 0.798665417515059 0.0542784656466697 460.600012207031 8 32323 2 0.980000019073486 -1 2473341 660168.786191338 2084722.77336542 460.699987792969 0.798665420423941 0.0542784656466697 460.699987792969 8 32324 2 1.25 -1

Bus_InterfaceGps__dev_ttyACM0_GGA_all.txt

476121 660168.799340458 2084722.75496854 460.600012207031 0.798665417515059 0.0542784685555518 460.600012207031 8 32322 2 0.980000019073486 -1
1475353 660168.786374253 2084722.75484107 460.600012207031 0.798665417515059 0.0542784656466697 460.600012207031 8 32323 2 0.980000019073486 -1
2473341 660168.786191338 2084722.77336542 460.699987792969 0.798665420423941 0.0542784656466697 460.699987792969 8 32324 2 1.25 -1

Tracks files

Additionnaly, we provide the trajectory in GPX and KML formats (track) in the files ID_INTERFACE_GPX.gpx and ID_INTERFACE_KML.kml.

For the GPX file, the schema version 1.1 is used (http://www.topografix.com/GPX/1/1/). In ID_INTERFACE_GPX.gpx, the GPS data are encoded as a track (an ordered collection of points). For each trackpoint, the following tags are filled: latitude and longitude (in decimal degrees, WGS84 datum), elevation, fix, hdop, sat, ageofdgpsdata and time are filled. The trajectory has been converted to the KML format (format of the Google file used to display geographic data in Google Earth and Google Map) using GPX to KML online converter.
Show example

Sample for GPS sensor of id ID_INTERFACE=Bus_InterfaceGps__dev_ttyACM0:

	Bus_InterfaceGps__dev_ttyACM0_GPX.gpx
	<?xml version="1.0" ... ... <trk> <trkpt lat="45.76015767" lon="3.109927167"> <ele>460.6000122</ele> <fix>2</fix> <sat>8</sat> <hdop>0.9800000191</hdop> <ageofdgpsdata>-1</ageofdgpsdata> </trkpt> ... </xml>

Satellites in View

Data about the satellites that the unit might be able to find are extracted from the GSV sentences (refer to http://www.gpsinformation.org/dale/nmea.htm#GSV) and are given in the file ID_INTERFACE_GSV.txt.

line	ID_INTERFACE_GSV.txt
	Rtime	nb_sat	nb_sat_data	idcanal_1	el_1	az_1	SNR_1	...	SNR_12

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
nb_sat_data is the number of satellites with available GSV data
idcanal is the satellite PRN number
el is the elevation angle, expressed in degrees
az is the azimuth angle, expressed in degrees
SNR is the Signal to Noise Ratio
idcanal, el, az and SNR are given for each (possible) 12 satellites.

Show example

Sample for GPS sensor of id ID_INTERFACE=Bus_InterfaceGps__dev_ttyACM0:

line	Bus_InterfaceGps__dev_ttyACM0_GSV.txt
	476606 11 3 2 0.453785598278 0.907571196556 40 12 0.558505356312 1.53588974476 39 14 0.331612557173 3.92699074745 38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 476850 11 3 25 1.20427715778 1.1344640255 40 29 1.46607661247 3.35103225708 40 30 0.209439516068 5.02654838562 25 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 476975 11 3 33 0.593411922455 3.57792496681 35 39 0.575958669186 2.61799383163 34 40 0.296705961227 2.07694172859 65535 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

line

Bus_InterfaceGps__dev_ttyACM0_GSV.txt

476606 11 3 2 0.453785598278 0.907571196556 40 12 0.558505356312 1.53588974476 39 14 0.331612557173 3.92699074745 38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
476850 11 3 25 1.20427715778 1.1344640255 40 29 1.46607661247 3.35103225708 40 30 0.209439516068 5.02654838562 25 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
476975 11 3 33 0.593411922455 3.57792496681 35 39 0.575958669186 2.61799383163 34 40 0.296705961227 2.07694172859 65535 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

NMEA sentences

For persons that are accustomed to processing directly the NMEA sentences, those sentences are listed in the file ID_INTERFACE.txt and can be accessed with their acquisition time using the file ID_INTERFACE.dates.

line	ID_INTERFACE.dates
#1 (header)	Version XXX
	sentence_type	numchar	Rtime'	Rtime'+latency'	latency'

Details:

sentence_type is the type of sentence: GGA or GSV
numchar is the number of characters in the file ID_INTERFACE.txt until the sentence is printed
Rtime' is the reception time expressed in hour:minute::second.microseconds from the beginning of the acquisition
latency' is the latency, expressed in hour:minute::second.microseconds

Proprioceptive sensors

Multiple proprioceptive sensors are put on the vehicle: motor encoder, steergin angle encoder, right and left wheels encoders, accelerometers and a magnetometer. For those sensors, both estimated data (using estimated parameters) and raw data are provided.

Motor encoder

line	ID_INTERFACE_Motor.txt
	Rtime	dt_odo_motor	transl_vel	distance_odo	direction	raw_speed	raw_odom

Details:

transl_vel is the translationnal velocity, expressed in m/s
distance_odo is the estimated distance travelled by the robot, expressed in m
These elements are computed using the following formula:

According to the datasheet, the speed encoder has a resolution of 0.001 m/s thus we set kspeed = 1./(0.001). (64 is the number of tops by revolution)
The diameter of the wheel (wheel_diameter) is 49cm (but depends on the pressure of the wheel), the motor_ratio is 1/9.9 thus the travelled distance is k_distance_odo=0.0024 m.
direction is the direction of the vehicle:
- 0: the vehicle is at rest
- 1: the vehicle is moving forward
- 2: the vehicle is moving backward
raw_speed is the speed measured by the motor odometry. We supposed that the translationnal velocity is proportionnal to the raw value:

The value of the parameter according to the datasheet is: kspeed=1./(0.001)(resolution 0.001 m/s)
For our sensor, we estimate those values to be:

kspeed 1095.
raw_odom is the value of the motor encoder counter. We supposed that the distance travelled by the vehicle is proportionnal to the raw value.
The value of the parameter according to the datasheet is: kodom=1./(0.001)(resolution 0.001 m/s)

Steering angle encoder

line	ID_INTERFACE_Steering.txt
	Rtime	steering_angle	raw_steering_angle

Details:

steering_angle is the steering angle, expressed in radians
rawsteering_angle is the steering angle encoder value (int16_t). We supposed that the steering angle is a linear function of the raw value:

The values of the parameters according to the datasheet are: kangle=1./(60.*π/180.0/32768.)(-60deg < steering_angle (deg) < +60deg; resolution of 0.002deg) and offset_angle=0.
For our sensor, we estimate those values to be:

kangle 31060. offset_angle -0.004

Wheel encoders

line	ID_INTERFACE_Wheels.txt
	Rtime	dt_odo_right	speed_right	dist_right	dt_odo_left	speed_left	dist_left	raw_speed_right	raw_odo_right	raw_speed_left	raw_odo_left

Details:

speed_right is the speed of the right rear wheel, expressed in rad/s
dist_right is the distance travelled by the right rear wheel, expressed in meters
speed_right and dist_right are computed using the following formula:
(128 is the number of tops by revolution)
We suppose that kspeed as a resolution of 0.001 m/s and the diameter of the wheel (wheel_diameter) is 49cm (thus the resolution is approximately of 1cm).
speed_left and dist_left are data for the left rear wheel.

With wheels about 40 cm in diameter, this represents approximately 2cm per "top" (0.40 * 3.14/64) - Specific calibration data (see [Calibration]) allow you to specify this value as we did above for the main odometer vehiucle

Accelerometers

line	ID_INTERFACE_Acc.txt
	Rtime	accX	accY	accZ	acc1	acc2	acc3	raw_acc1	raw_acc2	raw_acc3

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
accX, accY and accZ are the estimated values of the accelerations expressed in m/s² in the sensor frame
acc1, acc2 and acc3 are the estimated values of the accelerations expressed in m/s² in each direction separatly
raw_acc1, raw_acc2 and raw_acc3 are the raw values of the accelerations measured by the accelerometers (encoded in uint16_t; 65536 values). We supposed that the acceleration (accx for instance) is a linear function of the raw value:

The values of the parameters according to the datasheet are: kacc1=kacc2=kacc3=1./(2*20.20125/65536.) and offset_acc1=offset_acc2=offset_acc3=0 (null offset and -20.20125 < acc (m/s2) < +20.20125). For our sensor, we estimate those values to be:

acc1 acc2 acc3

kacc1 1610.0 kacc2 1622.4 kacc3 1610.6

offset_acc1 0.935 offset_acc2 -0.767 offset_acc3 1.876

acc1	acc2	acc3
kacc1	1610.0	kacc2	1622.4	kacc3	1610.6
offset_acc1	0.935	offset_acc2	-0.767	offset_acc3	1.876

Gyrometer

line	ID_INTERFACE_Gyro.txt
	Rtime	wz	temp	raw_wz	raw_temp

Details:

Rtime is the reception time expressed in microseconds from the beginning of the acquisition
wz is the estimated value of the angular velocity, expressed in rad/s
temp is the estimated value of the temperature, expressed in deg Celsus.
raw_wz is the raw value of the angular velocity measured by the gyrometer (encoded in uint16_t). The estimated value is computed using the following formula:

According to the datasheet, -93.75deg/s < wz (deg/s) < 93.75deg/s and rawwz is encoded by 2 bytes (65536 values) thus we set k_wz=1./(187.5π/180./65536.) and offset_wz=-93.75π/180.
raw_temp is the raw value of the temperature measured by the gyrometer (encoded in uint16_t). The estimated is computed using the following formula:

The values of the parameters according to the datasheet are k_temp=1./(500./65536.) and offset_temp=-225.0 (null offset and -225 degC < temp (degC) < +275 degC)

Other data

Dead-reckoning from odometry

The 2D positions and orientations of the vehicle are dead reckoned using knowledge about a vehicle's course and speed over the period of time using the motor and steering angle data (file ID_INTERFACE_DeadReckoned_Poses.txt).

line	ID_INTERFACE_DeadReckoned_Poses.txt
	Rtime	x	y	theta

Details:

[x;y]^T is the position of the vehicle estimated using odometry data, expressed in meters. When the application starts, [x_[0];y_[0]]^T=[0;0]^T.
theta is the orientation of the vehicle estimated using odometry data, expressed in radians. When the application starts, theta_[0]=0.

(Ackerman's model)
We have supposed here that the steerting angle measurement time is the same as the translationnal velocity (which is not the case).
In our vehicle, the rear axle measures length_rear_axle=1.21 m.

A second file is provided where the 2D positions and orientations of the vehicle are dead reckoned using a geometric evolution model (file ID_INTERFACE_DeadReckoned_Poses2.txt). It can be more accurate than the first file because it does not use the velocity (which is computed by integrating the motor encoder value by the time) but directly the displacement.

line	ID_INTERFACE_DeadReckoned_Poses2.txt
	Rtime	x	y	theta

Show example

Sample for interface of id ID_INTERFACE=Bus_InterfaceCan_can0 and vehicle sensor:

	Bus_InterfaceCan_can0_DeadReckoned_Poses2.txt
	14816 0 0 0 34829 0 0 0 54829 0 0 0 74822 0 0 0

Clock synchronization

A log of the clock synchronization of the client is sometimes provided (file .log).

line	ntpupdate.log
	AbsTime	offset

Details:

AbsTime is the UTC time of the computer when the clock is synchronized expressed in microseconds.
offset is the difference between the time of the client and the time of the server before synchronisation, expressed in seconds.

The Institut Pascal Data Sets Sets of multisensors' timestamped data with ground truth, calibration data and software sources

Logs format

VISUAL SENSORS

Images and timestamp

RANGE SENSORS

Range sensor impacts and timestamp

GPS sensors

3D location and accuracy data

Tracks files

Satellites in View

NMEA sentences

Proprioceptive sensors

Motor encoder

Steering angle encoder

Wheel encoders

Accelerometers

Gyrometer

Other data

Dead-reckoning from odometry

Clock synchronization

The Institut Pascal Data Sets
Sets of multisensors' timestamped data with ground truth, calibration data and software sources