This data set is from an autonomous exploration of the area outside our building.  As the robot was moving on its own, some of the decisions were not the best from the map making point of view.  That is one of the things that make this data set challenging.  The other is the fact that the laser scan data is from a real outdoor environment and contains things like fences, hedges, hills and so on.

While being challenging it is possible to 'solve' this data set .

I have also provided a file with a list of the walls of our building.  The map of the building is given here  map.dat  and can be view in matlab with  mapsee.m  .  This can be used to check the accuracy of the map.
 

The robot starts at coordinates 37.9552 5.94152 1.39301, which is about the center bottom of the map.  it then proceeds counter-clockwise around the building ending up about where it started.

Dataset1 provides the raw data, odometer, inertial and SICK.

In Dataset2 I have  provided a file with  fused dead-reckoning estimates.  This used the inertial and odometer readings to estimate the pose of the laser at the time of the laser scans.  The format is timestamp x y z theta phi psi then the next 9 numbers are the covariance of the change in x y and theta since the previous estimate.

The fused estimate has been moved to agree with the map at the start and it has the laser offsets added in.  You can see this if you plot the x y in matlab.  You will then see smal l circles when the robot is spining about its center,  something the explore algoritm makes it do sometimes.  These circles don't appear in the odometer data as that is giving the x and y of the center of the robot.

The scan data consists of 181 scan points 1 degree apart from a scanner facing forwards, about 70 cm high from the ground.    The laser is mounted 20 cm forward of the center of the robot.  This means the LASER_OFFSET=(dx dy dtheta) = (0.20 0  0.70)

Note that the fused data is the location of the SICK scanner and not the robot center so for that data no offsets (time or space) need to be added.   I know I said this many different ways but it hurts to get these things wrong and waste lots of time.

The fused data might make things easier as it is not straight forward or fun to do this fusing for those that just want to test a SLAM algorithm.

Another hint would be to filter the features well.  You can detect some of the bad features by removing moving objects ect.  (the problem is not moving objects but scans that appear to be from moving objects)

Scan matching has not been done with this and I think there might be difficulties using it, but I may be wrong.  The problem is the robot moves along with walls to its left and nothing else much of the time.  This doesn't give scan matching  enough information as it need to be able to specify both x , y and theta well, as opposed to  just x and theta.

For some more background and examples of SLAM with this data one can look at these papers:

Back to main page

John Folkesson johnf@nada.kth.se