#  Introduction

This document deals with the research data produced, collected and preserved
during the project. This data can either be made publicly available or not
according to the Grant Agreement and to the need of the partners to preserve
the intellectual property rights and related benefits derived from project
results and activities.

Essentially the present document will answer to the following main questions:

  * What types of data will the project generate/collect? 

  

  * What data is to be shared for the benefit of the scientific community? 

  

  * What format will it have? 

  

  * How will this data be exploited and/or shared/made accessible for verification and re-use? 

  

  * What data cannot be made available? Why? 

  

  * How will this data be curated and preserved? 

  

The data is made available as Open access research data; this refers to the
right to access and re-use digital research data under the terms and
conditions set out in the Grant Agreement. Openly accessible research data can
typically be accessed, mined, exploited, reproduced and disseminated free of
charge for the user.

The FLOBOT project abides to the European Commission's vision that information
already paid for by the public purse should not be paid for again each time it
is accessed or used, and that it should benefit European companies and
citizens to the full. This means making publicly-funded scientific information
available online, at no extra cost, to European researchers, innovative
industries and citizens, while ensuring long-term preservation.

The Data Management Plan (DMP) is not a fixed document, but evolves during the
lifespan of the project. The following are basic issues that will be dealt
with:

  * **Data set reference and name**

  

The identifier for the data sets to be produced will have the following
format:

Flobot_[taskx.y]_[descriptive name]_[progressive version number]_[date of
production of the data]

  * **Data set description**

  

Description of the data that will be generated or collected will include:

  * Its origin, nature, scale and to whom it could be useful, and whether it underpins a scientific publication. Information on the existence (or not) of similar data and the possibilities for integration and reuse. 

  

  * Its format 

  

  * Tools needed to use the data (for example specialised software) 

  

  * Accessory information such as video registration of the experiment or other. 

  

  * **Standards and metadata**

  

Reference to existing suitable standards of the discipline. If these do not
exist, an outline on how and what metadata will be created.

  * **Data sharing**

  

Description of how data will be shared, including access procedures, embargo
periods (if any), outlines of technical mechanisms for dissemination and
necessary software and other tools for enabling re-use, and definition of
whether access will be widely open or restricted to specific groups.
Identification of the repository where data will be stored, if already
existing and identified, indicating in particular the type of repository
(institutional, standard repository for the discipline, etc.). In case the
dataset cannot be shared, the reasons for this should be mentioned (e.g.
ethical, rules of personal data, intellectual property, commercial, privacy-
related, security-related).

  * **Archiving and preservation (including storage and backup) and access modality**

  

Description of the procedures that will be put in place for long-term
preservation of the data. Indication of how long the data should be preserved,
what is its approximated end volume, what the associated costs are and how
these are planned to be covered.

The present Data Management Plan will answer to the following questions:

Is the Scientific research data easily:

  1. **Discoverable.** Is the data and associated software produced and/or used in the project discoverable (and readily located), identifiable by means of a standard identification mechanism (e.g. Digital Object Identifier)? 

  

  2. **Accessible** . Is the data and associated software produced and/or used in the project accessible and in what modalities, scope, licenses (e.g. licencing framework for research and education, embargo periods, commercial exploitation, etc.)? 

  

  3. **Assessable and intelligible** . Is the data and associated software produced and/or used in the project assessable for and intelligible to third parties in contexts such as scientific scrutiny and peer review (e.g. are the minimal datasets handled together with scientific papers for the purpose of peer review, is data provided in a way that judgments can be made about their reliability and the competence of those who created them)? 

  

  4. **Useable beyond the original purpose for which it was collected** . Is the data and associated software produced and/or used in the project useable by third parties even long time after the collection of the data (e.g. is the data safely stored in certified repositories for long term preservation and curation; is it stored together with the minimum software, metadata and documentation to make it useful; is the data useful for the wider public needs and usable for the likely purposes of non-specialists)? 

  

  5. **Interoperable to specific quality standards** . Is the data and associated software produced and/or used in the project interoperable allowing data exchange between researchers, institutions, organisations, countries, etc. (e.g. adhering to standards for data annotation, data exchange, compliant with available software applications, and allowing re-combinations with different datasets from different origins? 

  

  

#  Data generated in FLOBOT

##  Floor visual analysis, Floor cleaning quality control and Object
identification data

The data is collected during lab tests and during preliminary visits to the
end-user sites, demonstration sites and similar target locations, such as
various supermarkets. Data collected is related to the developments of T5.3
and T5.4. The data will be collected continuously during the first 30 months
of the project. The data will be available at project end. The format of the
data is the Rosbag file format (binary data container file), available in the
ROS framework. The format is ROS internal and allows reproducing the test
scenarios at any time. The disadvantage is that the amount of data is large,
as indicated below.

The database structure is a sequence of images from the sensors of the robot.
The current sensor setup includes: 2x RGB-D sensors, 2x stereo cameras, 1x
Laser Line Scanner. Sequences may also be recorded with fewer sensors. The
files size depends on the data rate: it is estimated to 800 MB / sec
(uncompressed) and 270 MB / sec (zipped).

The scientific data standards to be used are the ROS formats. We plan to
adhere to this widely used format. We will also create annotated metadata. The
metadata will contain masks for the potential output of the method. Masks will
be in binary format, as also used in ROS.

For the evaluations, we will also collect and make available ground truth
data. This will be achieved manually by annotation of the acquired Rosbag
camera images. This needs to be done per frame and is time consuming. There
exists also a similar framework for evaluation, created by Bormann et al  1  .
It may be possible to use this framework, even if the application scenario
differs. However, this possibility requires further investigation, since it
requires extensive knowledge of ROS and the framework code to run.

The possible use or re-use by the scientific community is provided by adhering
to ROS conventions.

_Information about tools and instruments_ : As outlined before, it is planned
to investigate and use specific tools described earlier. If this will not be
possible, we will attempt to provide different tools or produce data in a way
that the format given is adequate for easy re-use by the scientific community.

Regarding scientific papers to be used as key explication of the data meaning,
value, and use, we plan an ICRA  2  or IROS  3  submission with the Data and
first evaluations.

_Interoperability to specific quality standards_ : The data and associated
software produced and/or used are interoperable, allowing data exchange
between researchers, institutions, organisations, countries, etc. (e.g.
adhering to standards for data annotation, data exchange, compliant with
available software applications, and allowing re-combinations with different
datasets from different origins).

_Accessibility_ : The data and associated software produced and/or used will
be freely accessible.

##  Human tracking for safety data

The data is collected for Task 5.2 during lab tests and preliminary tests on
site of the demonstration. The data will be available at the end of the
project.

The format of the data depends on the sensor used. In general, the Rosbag file
format (binary data container file) from the ROS framework will be used. The
format is ROS internal and allows reproducing the test scenarios at any time.
Alternatively, the ‘pcap’ format (packet capture) will be used for laser data
only.

The database structure is a sequence of images and laser scans from the robot
sensors. The current sensor setup includes: 1x RGB-D sensor, 1x 3D laser
(LIDAR). Sequences may also be recorded with each sensor individually. Where
available, information from the robot odometry sensors will also be recorded.

The expected size of the files is in the order of hundreds of MBs per second,
depending on the sensor reading rate (i.e. 20÷30 Hz).

As in the previous case, the scientific standards and metadata are the ROS
formats, since these are the most widely used in the robotics community. We
will also create annotated metadata containing masks (i.e. ROS binary format)
for the potential output of the human tracking system. Ground truth data will
be created by manually annotating the acquired Rosbag data for evaluation
purposes. Further details regarding tools for data annotation will become
available during the actual development stage of the project.

The possible use or re-use by the scientific community is made possible by
adhering to the ROS standards. Information about tools and instruments at the
disposal of the beneficiaries will be those provided by the ROS community and
those developed, where necessary, by the partners for internal and external
use.

Expected scientific papers to be used as key explication of the data meaning,
value, and use are planned for the IEEE ICRA or IEEE/RSJ IROS conferences, as
well as a high-impact robotics journal (e.g. IJRR  4  ).

Interoperability to specific quality standards will be achieved by adhering to
the aforementioned formats. The data will be freely available.

##  Navigation and mapping data

_Mapping data_

The data is collected during task 5.1 at M9 and M10 on at least one
demonstration site, to enable unitary test during the development. The final
mapping data is collected, in two stages, one in the beginning of task 6.2 at
M19 and the other during the setup on task 7.3 at M28. The data will be
available at M32.

The local mapping will be done through several layers of the map:

  * Localisation map : contains a bitmap of the land occupation ; its resolution (float) and origin (two floats) 

  

  * Semantic map : contains a bitmap of metadata, splits the surface into zones 

  

  * Points of interest : a list of points (each one represented by two float coordinates) 

  

The size of the bitmap will depend on the working surface and the resolution
required. For example, a 10.000m² square-shaped surface at 5cm resolution
would require a 2000*2000 pixels bitmap (each pixel contains 1 byte of data).
This bitmap would be susceptible to change at most once a day. With a 75%
compression (under .png format), saving this data would require 1 MB of memory
each day in this example.

The data (bitmap produced by mapping module) will be made available under a
licence agreement that makes it freely available for non-commercial use,
provided to have the prior approval of the FLOBOT consortium, Robosoft and
demonstration site owner (ex. For secure sites, like the airports).

_Navigation and obstacle detection data_

The data is collected during task 7.3 at M34 on site of the demonstration. The
data will be available at M35.

The path of the robot will be given as a series of segments and smooth turns
(Bézier curves). Each segment will be defined by two points (4 float
coordinates), each Bézier curve requires 6 points (12 float coordinates). The
robot will receive its initial path and might have to modify it (if an
obstacle lies in its path for instance). To record this, the robot will have
to memorise each order it followed (i.e.: each segment or Bézier curve it
effectively tried to follow). Thus, if a part of the path was aborted for some
reason, it will not be saved.

The instruments are able to estimate the path of the robot, which will
slightly differ from its instructions. This will only be recorded as a series
of points, updating regularly the position of the robot. Saving the initially
instructed path, the followed path and the estimated path used by a robot
should not require more than 300 kB/h.

The data (path produced by the navigation module) will be made available under
a licence agreement that makes it freely available for non-commercial use,
provided to have the prior approval of the FLOBOT consortium, Robosoft and
demonstration site owner (ex. For secure sites like the airports)

The state of the robot includes the following data:

  * battery level (a _float_ representing the percentage left) 

  

  * position (three _floats_ representing the measured coordinates x, y and orientation theta) 

  

  * speed (two _floats_ , one for the speed V and one for the angular speed omega) 

  

  * covariance (covariance of the position measure, three _floats_ : covar(x), covar(y) and covar(theta) ) 

  

  * state of the cleaning system (TBD as the project progresses. It should at least describe whether the system is working or not) 

  

  * task of the robot (one integer which will code the present task : cleaning, going home...) 

  

  * action of the robot (one integer which will code the present action : following the mission, avoiding an obstacle…) 

  

The robot will also be able to receive a direct instruction (two _floats_
V_instruction and omega_instruction). Memorising the state of the robot every
second should require at most 500 kB/h.

The 3D RGBD cameras will supply data under the ROS format sensor_msgs/Image.
They will supply a standard RGB image and a depth image. The LIDAR will
produce a 3D point cloud under the ROS format sensor_msgs/PointCloud. The
image, the depth image and the point cloud are not to be saved. They represent
huge amounts of data updated at a high frequency and cannot be memorised by
the robot.

The data (state of the robot produced by the low-level and high-level control
module developed by Robosoft) will be made available under a licence agreement
that makes it freely available for non-commercial use, provided to have the
prior approval of the FLOBOT consortium and Robosoft.

Regarding the API (protocol of communication and technical details exchanged
between Robosoft and other partners), any commercial use is strictly
prohibited without Robosoft’s prior written consent. Partners shall not
distribute, sell, lend or otherwise make available or transfer to a person
other than the Partners or an entity not party to this agreement and in this
project frame, the technical details, for any reason, without Robosoft’s prior
written agreement.

To protect the competitive advantage of the research and development
activities of the FLOBOT consortium, the software code, algorithm, protocol,
technical drawing and sketches, produced and used by this module, are not
accessible by public. In this way, FLOBOT consortium will have the option to
seek patent protection.

##  Environment reasoning and learning data

The data is collected during task 7.3 at M34 on site of the demonstration. The
data will be available at M35.

The learning and reasoning module will collect data while the FLOBOT moves.
This module will in particular check the presence of new obstacles. If a new
obstacle appears recurrently on the map, it will be added in the land
occupation map. Similarly, if an obstacle disappears, it will be removed from
the land occupation map. Both those functionalities will be achieved through
machine learning (reinforcement learning). If a point of interest cannot be
thoroughly cleaned, it will be added as non-cleanable in a corresponding layer
map. This layer map will be (very much like the maps of the navigation &
mapping modules) a bitmap.

The learning module will require data from the turbidity sensor. Thanks to
this data, the robot will be able to evaluate the dirtiness of its area while
cleaning. This data will be transferred to the database, which will in turn be
able to draw a bitmap of the frequently unclean areas (same format as the
other bitmap layers).

To protect the competitive advantage of the research and development
activities of the FLOBOT consortium, the software code, algorithm, protocol,
technical drawing and sketches, produced and used by this module, are not
accessible by public. In this way, FLOBOT consortium will have the option to
seek patent protection.

##  Proactive safety module data

The proactive safety module is a safety feature offered by FLOBOT and its aim
is to warn people about the FLOBOT presence, as well as about its next
movement. The corresponding task is T5.9. Data is collected both during the
development phase (T5.9) and during the validation phase (T6.4 – Laboratory
tests, T7.2 – Prevalidation first testing, T7.3 – Pre-validation second
testing, T7.4 – Qualification review).

The first data will be available by month 20, while data will continue to be
collected up to the end of the project in month 36.

The proactive safety module relies on the indications received by the FLOBOT
main controller, regarding the next move of the robot and the environment
around it, in order to project the necessary information. The data that is
considered interesting for the scientific community and which will be
collected relate to: a) the performance of the module in various lighting
conditions and b) the adaptation of the projection distance, depending on the
floor inclination and/or position of nearby obstacles.

Regarding the first type of data (various lighting conditions), datasets
collected will be formatted as follows:  
  
<table>  
<tr>  
<th>

Measurement index

</th>  
<th>

Timestamp

</th>  
<th>

Location

</th>  
<th>

Surface type

</th>  
<th>

Light intensity

</th>  
<th>

Image of the projection

</th> </tr> </table>

Light intensity will be measured using a standard light sensor. The output of
the module (projected images) will be captured using a hi-end camera and will
be used to compare the visibility of the projections in varying light
conditions.

Regarding the data collected for evaluating the module’s behaviour in
different floor inclinations and surrounding environment conditions, those
will be structured as follows:  
  
<table>  
<tr>  
<th>

Measurement index

</th>  
<th>

Timestamp

</th>  
<th>

Location

</th>  
<th>

Surface type

</th>  
<th>

Surface inclination

</th>  
<th>

Laser projection angle

</th>  
<th>

Image of the surrounding obstacles

</th>  
<th>

Image of the projection

</th> </tr> </table>

Surface inclination will be measured using an inclinometer, while laser
projection angle will be measured on the robot (angle of turn of the servos).
High resolution images of the surroundings and of the projection will also be
included in the dataset.

Data will not be assigned a DOI, but they will be discoverable through the use
of major search engines. In fact, the

FLOBOT website will be promoted through search engine optimization techniques
and the project results (including links to the datasets) will also be
disseminated through social media (Facebook, Twitter). Data will be shared
with the community free of charge for use in non-commercial applications.
Descriptive metadata will also be produced to describe: the camera used to
take the pictures and the corresponding project task.

The expected file size _per entry_ is estimated at about 2 MB for the first
case (various lighting conditions) and 4 MB in the second one.

No specialized software or tool is necessary for processing the datasets and
evaluating the module’s performance. The evaluation of the FLOBOT proactive
safety module, using the collected data, will be made by the project partners
during the final stages of the project. The results might be published in
scientific journal or conferences, if deemed necessary by the management
board.

Proactive module datasets will be made available through the project website,
in the same way all publicly available FLOBOT research data will be published.
Details are presented in the appropriate section of this document.

##  Tools for psychological impact and user's evaluation

The tools will be made available under a license agreement that makes them
freely available for non-commercial use, provided the FLOBOT consortium and
the owner of the corresponding IPR (RBK) are duly acknowledged.

#  Data sharing

Most literature, including scientific data, will be published and hosted as
per individual availability on the project’s public website i.e.
_www.flobot.eu_ . The only literature that will not be published is the one
pertaining to patent protection as defined in the previous sections.

The website has a friendly and easy to use navigation. It will be modified in
due time to accommodate additional sections (Categories) where all the
necessary literature will be stored, these will be:

  1. Floor Visual Analysis Module and Data 

  

  2. Floor Cleaning Quality Control Module and Data 

  

  3. Object Identification Module and Data 

  

  4. Human Tracking for Safety Module and Data 

  

  5. Navigation and Mapping Module and Data 

    1. Mapping Data 

  

    2. Navigation and Obstacle Detection Data 

  
  

  

  6. Environment Reasoning and Learning Module and Data 

  

  7. Proactive Safety Module and Data 

  

  

The data will be made available on the website through a Wiki module, which
will be presented as a Knowledge Base facility. Each section will have its own
page and consequent subpages. The wiki pages will cover the topics and project
descriptive information to an appropriate level for each set of information or
dataset.

The data will be formatted as per the description of each section, provided
previously in this document, and will be presented for access along with the
necessary links to download the appropriate software tools, if necessary. Each
downloadable bit of information will be encompassed by its own wiki page,
which will also enclose all necessary additional downloadable tools.

The wiki pages will be available to the public domain, enriched with the
necessary metadata and will be open to web crawlers for search engine listing,
so they will be available to the public through standard web searches.

Despite the publicly available wiki pages, the downloadable data will be
presented along with the restrictions provided in each previously described
section. This means that the following will apply on the website in order to
gain access to the information:

  1. Terms and Conditions will apply and will have to be accepted prior to any download 

  

  2. Registration will be compulsory (free of charge) to maintain a data access record 

  

  3. For certain and limited amount of datasets, a form will be available to request access to the data, but this will be subject to approval from the consortium 

  

  

Please note that all datasets will be under the ROS framework standard or the
PCAP format which means that the data will not need to be available through a
published API, the entire binary set can be downloadable and accessed through
publicly available tools.

Additional downloadable formats will be:

  1. PNG, BMP and JPEG file formats 

  

  2. ZIP and other public domain compressed archives 

  

  3. PDF formatted documents 

  

  

#  Archiving, preservation and access modality

The data in all the various formats will be stored in standard storage. It has
been mentioned in the previous section that no specialised storage or access
is necessary, as all datasets will be downloadable in their entirety.

All the information, including the descriptive metadata will be available
throughout the lifetime of the website, which is expected to be in the public
domain for a period of at least five (5) years after the completion of the
project. Due to the unusually large size of individual downloadable files, the
storage used will be based on a Cloud based services and it is estimated
(based on current prices) to be according to the table below:

_Geographically Monthly Price Estimated Estimated Price per Estimated Price
over 5_

_Redundant Storage for per GB Storage month years_

_Disaster/Recovery requirements_

_purposes_  
  
<table>  
<tr>  
<th>

_First 1 TB/Per month_

_Next 49 TB/Per month_

_(1-50TB)_

</th>  
<th>

€0.0358 per GB

</th>  
<th>

1 TB (1024 GB)

</th>  
<th>

€36.66 per month

</th>  
<th>

€2,199.60

</th> </tr>  
<tr>  
<th>

€0.0352 per GB

</th>  
<th>

1 TB (1024 GB)

</th>  
<th>

€36.05 per month

</th>  
<th>

€2,162.69

</th> </tr> </table>

_€4,362.29_

Please note that we estimate a maximum of 2 TB of data to be made publicly
available. The cost of storage will be covered by the consortium members .

Please note that the prices are based on the Microsoft Azure current pricing (
_http://azure.microsoft.com/enus/pricing/details/storage/_ ).

Please note that some data may be stored under the facilities of the
consortium members that own them, but will still be referenced via the
website.

#  Conclusions

The Data Management Plan presented here describes the research data that will
be produced by each of the software-related tasks of the project and the way
that those will be made available. Information regarding data sharing,
archiving and preservation is also included. Essentially the DMP answers to
the following main questions: What types of data will the project
generate/collect? What data is to be shared for the benefit of the scientific
community? What format will it have? How will this data be exploited and/or
shared/made accessible for verification and re-use? What data cannot be made
available? Why? How will this data be curated and preserved?

Finally, a preliminary costing analysis has been made. It has to be clarified
that this Data Management Plan (DMP) is not a fixed document, but evolves
during the lifespan of the project.