Associated raw data to the PhD thesis: Design and evaluation of a camera-based indoor positioning system for forklift trucks

* The markers from the ArUco library are used (see https://www.uco.es/investiga/grupos/ava/node/26). * Read the thesis linked above for further insight into the test design (p.126-127) and evaluation methods (p.74-77). * You can get the sources to the forklift positioning demonstrator. (see https://github.com/emjay2k/FastMarkerLocalizer) * Originally these files were recorded and used as uncompressed 8-bit grayscale bitmaps. They were losslessly compressed to png files in order to reduce the test set file size (by approx. factor 3.5). * Sources are available to record such files (src/timestampedcameracapture.cpp) or play them back (src/timestampedvideocapture.cpp) using OpenCV 2.4.x (later versions untested). Relative timestamps are available in timestamps.yml and will be automatically used by this code and can be read in OpenCV through propid CV_CAP_PROP_POS_MSEC. * Check the "doc" subfolder for further information regarding the used camera parameters and other ground truth information (e.g. used industrial camera, calibration data, the marker position in 2D or 3D coordinates, etc). * Only the images taken from the industrial camera are available (see below why there are no recordings from the Raspberry Pi) * For the Raspberry Pi based demonstrator the recorded positions and related information is available instead as "raw data". While this data may allow further analysis of the existing algorithm, it cannot be used to test other algorithms, hence you will need to build a test enviroment for this step yourself. Caveats * The ground truth of the camera calibration data is usually unknown for real cameras. It was therefore estimated using the method from the paper ("Accurate Camera Calibration using Iterative Refinement of Control Points", by Datta, Kim and Kanade). * Subfolder rpitest was recorded with a Raspberry Pi model B and a Picamera 1.3 instead (a full 8 shaped course). This recording is just to show why this slow hardware cannot be easily used to record a data set similar to the one provided. The hardware cannot keep up with recording data in uncompressed form because its SDCard interface bandwidth is too slow and compressed data recording is throttled by its poor CPU performance. Hence the huge gaps, when the data was written from memory to SDCard and blocked further IO (recordings) resulting in long sequences of dropped frames. Other reasons also make it difficult to obtain a decent recording in difficult situations (see https://mediatum.ub.tum.de/?id=1395267 p.143). However one can still use that setup for real-time locating if you apply a few tricks (see p.142-153).