Embed Size (px)
Citation preview
Grant Agreement Number: 687458
Project acronym: inLane
Project full title: Low Cost GNSS and Computer Vision Fusion for Accurate Lane Level
Navigation and Enhanced Automatic Map Generation
D. 7.3
Periodic report
Due delivery date: M18
Actual delivery date: M18
Organisation name of lead participant for this deliverable: VICOM
Project co-funded by the European Commission within Horizon 2020 and managed by the European GNSS Agency (GSA)
Dissemination level
PU Public X
PP Restricted to other programme participants (including the GSA)
RE Restricted to a group specified by the consortium (including the GSA)
CO Confidential, only for members of the consortium (including the GSA)
2
Document Control Sheet
Deliverable number: D7.3
Deliverable responsible: VICOM
Work package: WP7
Editor: Gorka Vélez
Author(s)
Name Organisation E-mail
Oihana Otaegui VICOM [email protected]
Gorka Vélez VICOM [email protected]
Esther Novo VICOM [email protected]
Martí Massot ACASA [email protected]
François Fischer ERTICO [email protected]
Gijs Dubbelman TUE [email protected]
Jos den Ouden TUE [email protected]
Claudia Fösleitner TCA [email protected]
Axel Koppert TCA [email protected]
Benedict Flade HRI [email protected]
Alex Unnervik INTEL [email protected]
Martijn de Greef TOM TOM [email protected]
David Betaille IFSTTAR [email protected]
Document Revision History
Version Date Modifications Introduced
Modification Reason Modified by
V0.1 2017-05-23 Table of contents Gorka Vélez
V0.2 2017-06-26 First draft All contributors
V1.0 2017-06-30 Final version reviewed Esther Novo
3
Abstract
This document contains the technical periodic report corresponding to the first 18 months of the project. An official periodic report will be submitted by the coordinator within 60 days following the end of the first reporting period. The complete report will contain the periodic technical and financial reports. However, this deliverable summarises only the technical progress of the inLane project during the period 2016.01.01-2017.06.30. Moreover, the technical report will be update again after the reporting period has finished.
The procedures described in this deliverable are aligned with the information already provided in the Description of Action for inLane (as per Grant Agreement number 687458).
Legal Disclaimer
The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. © 2016 by inLane Consortium.
4
Table of Contents
1. Executive Summary ......................................................................................................................... 5
2. Introduction ...................................................................................................................................... 6
2.1 Purpose of document .............................................................................................................. 6
2.2 Intended audience ................................................................................................................... 6
3. Explanation of the work carried out by the beneficiaries and overview of the progress .................. 7
3.1 Objectives ................................................................................................................................ 7
3.2 Explanation of the work carried out per WP .......................................................................... 10
3.2.1 WP1: Requirements, specification and architecture definition .......................................... 10
3.2.2 WP2: GNSS and vision-based road and scene element geolocalisation and characterisation .............................................................................................................................. 13
3.2.3 WP3: Applications: Crowdsourcing enhanced map generation in real time and lane-level navigation ....................................................................................................................................... 19
3.2.4 WP4: Integration and testing ............................................................................................. 23
3.2.5 WP5: Lane-level guidance pilot – user ............................................................................. 28
3.2.6 WP6: Dissemination and exploitation................................................................................ 30
3.2.7 WP7: Management............................................................................................................ 33
4. Conclusions ................................................................................................................................... 35
List of Figures
Figure 1: Components for creating and updating lane-level accurate maps from crowdsourced data.
Existing components (black), components developed in inLane (green) and components developed in
parallel projects (red). ........................................................................................................................... 14
Figure 2: Output of TUE Visual odometry (middle) and SLAM optimization (right) and GPS ground
truth (left). .............................................................................................................................................. 14
Figure 3: visualization of the traffic sign detection on the navigation device and the aggregated
information in the back-office. ............................................................................................................... 20
Figure 4: 3D lane map presentation augmented with the lane plan (top) and the advice to change lane
(bottom) ................................................................................................................................................. 21
Figure 5: A visualization of the lateral depth off-set encoded in RoadDNA. ......................................... 21
Figure 6 Test vehicle (lateral) ............................................................................................................... 23
Figure 7 Test vehicle (front) .................................................................................................................. 24
Figure 8 Docker image project in inLane's GitLab ................................................................................ 24
Figure 9 Automatic build of the Docker image ...................................................................................... 25
Figure 10 inLane's Git repository (GitLab) ............................................................................................ 25
Figure 11 Test pyramid ......................................................................................................................... 26
Figure 12 Slack statistics for inLane ..................................................................................................... 33
5
1. Executive Summary
This document is the public deliverable D7.3 of the H2020 project entitled Low Cost GNSS and
Computer Vision Fusion for Accurate Lane Level Navigation and Enhanced Automatic Map
Generation, inLane. This document summarises the results accomplished during the first reporting
period, thus, from January 2016 to June 2017.
The aim of the inLane project is to deliver lane-level information to an in-vehicle navigation system
giving drivers the opportunity to select the optimal road lane, even in the case of dense urban and
extra-urban traffic. Moreover, inLane will reduce the risks associated with last-moment lane-change
manoeuvres and will enable a new generation of enhanced mapping information based on crowd
sourcing.
As part of the inLane project, WP7 has the following objectives:
• To achieve the objectives of the project in a cost-effective way, within the agreed time scale.
• To ensure that the project is conducted in accordance with any contractual agreement
between the Consortium and the EC, and to maintain a continuous link with the EC.
• To provide the overall scientific strategy and coordination of the project; establish the
cooperation agreement among the partners and steering their efforts.
• To continuous and effectively monitor the project and efficiently manage and mitigate possible
project risks.
6
2. Introduction
2.1 Purpose of document
This deliverable is intended to be a summary of all the work done during the first 18 months within the
inLane project, as it was defined in the Annex 1 of the Grant Agreement (Description of Action). This
deliverable follows a similar approach to the structure of the Part B of the Periodic Technical Report
Template. The complete and final version of the Periodic Report will be delivered within 60 days
following the end of the reporting period, including an updated version of this document.
The periodic technical report will consist of two parts:
• Part A of the periodic technical report will contain the cover page, a publishable summary and
the answers to the questionnaire covering issues related to the inLane project implementation
and the economic and social impact, notably in the context of the Horizon 2020 key
performance indicators and the Horizon 2020 monitoring requirements. Part A will be
generated by the IT system and will be based on the information entered by the participants
through the periodic report and continuous reporting modules of the electronic exchange
system in the Participant Portal.
• Part B of the periodic technical report is the narrative part that includes explanations of the
work carried out by the beneficiaries during the reporting period. This Part B will be based on
some of the information provided in this deliverable D7.3.
The periodic financial report will consist of:
• Individual financial statements (Annex 4 to the GA) for each beneficiary;
• Explanation of the use of resources and the information on subcontracting and in-kind
contributions provided by third parties from each beneficiary for the reporting period
concerned;
• A periodic summary financial statement including the request for interim payment.
2.2 Intended audience
The dissemination level of this deliverable is public. The intended audience is the general public, and
in particular European and international stakeholders in the areas of GNSS, Computer Vision, lane-
level navigation, data fusion, dynamic mapping and cartography.
7
3. Explanation of the work carried out by the beneficiaries and overview of the progress
3.1 Objectives
The aim of the inLane project is to deliver lane-level information to an in-vehicle navigation system
giving drivers the opportunity to select the optimal road lane, even in the case of dense urban and
extra-urban traffic. Moreover, inLane will reduce the risks associated with last-moment lane-change
manoeuvres and will enable a new generation of enhanced mapping information based on crowd
sourcing. As part of the inLane project, the following specific objectives have been defined:
Objective 1 To define user requirements that will be addressed by the inLane prototype,
whilst paying particular attention to the optimisation of four main areas:
accuracy, reliability, cost effectiveness and availability in urban and suburban
areas where GNSS use is challenging.
To define the system architecture and specifications in order to ensure the
perfect fusion of all components of the inLane system.
Work carried out
towards its
objective
The first version of requirements and architecture was defined in deliverable
D1.1.
Objective 2 To develop a low-cost EGNOS/EDAS + GNSS (GPS/GLONASS/Galileo) + IMU
+ Computer Vision based positioning module prototype for fast HW/SW in the
loop development, which will enable enhanced positioning capabilities and make
use of low-cost elements. This precise positioning module will have an interface
for linking with smartphone-like platforms for offering the users a friendly Human
Machine Interfaces (HMI). In the near future, when mobile phones phone include
Galileo capable chipsets this extra module will not be required.
Work carried out
towards it
The first version of this module was developed in WP2.
Objective 3 To develop new, computer vision based, road modelling (lane modelling), traffic
signal identification and road/traffic element tracking and identification. The road
model and the traffic signs will be geolocated according to data provided by the
precise positioning module. This road information will be used for creating a new
generation of enhanced maps that will enable new generation of driver
assistance application such as lane-level operations.
Work carried out
towards its
objective
The first version of lane modelling and traffic sign recognition modules were
developed in WP2.
Objective 4 To create a new generation of enhanced maps that will update continuously
thanks to crowdsourcing (information provided by all the inLane navigation
users). End-to-end solution will be generated for updating only specific
information. This will also imply the development of standards for coding new
road data content classes.
Work carried out
towards its
objective
An initial version of a backend server was developed in WP3 for automatic map
updates based on crowdsourcing.
8
Objective 5 To define and develop complex fusion and hybridisation algorithms for GNSS,
IMU, Map and Computer Vision technologies for reaching sub-metre accuracy
(precise in-lane position). Target performance: 5 cm accuracy related to
absolute location.
Work carried out
towards its
objective
An initial version of data fusion module for enhanced positioning estimation was
developed in WP2. First accuracy investigations show that we reach lane-level
accuracy in clear sky and rural scenarios. Real urban scenarios have to be
further investigated to get insights into the optimal tuning of the fusion
algorithms.
Objective 6 To validate the positioning performance improvement that can be expected from
Galileo and/or EGNSS + IMU + Computer Vision for cartography generation
applications.
Work carried out
towards its
objective
Further tests are required for this validation. This is expected to be done with the
last prototype.
Objective 7 To develop system integration into mobile phone platforms for quick prototyping,
and acceleration of the validation and testing process. Additionally, to define the
look and feel of a new handheld sensor-based device in terms of its commercial
market entry.
Work carried out
towards its
objective
An extended Alpha version of the Lane-level navigation application was
implemented on an off-the-shelve tablet (NVidia shield). This tablet was selected
instead of a smartphone because of its better GPU capabilities.
Objective 8 To implement a testing and dissemination phases that will be crucial for
assessing and validating functionality of the solution on the one hand and for
end-user acceptance on the other hand. Therefore 2 test phases will be defined,
the first one in an especially dedicated high performance test-site on the Dutch
A270 public highway, which will help to validate the requirements and
specifications and the second phase in pilot city of Barcelona involving end-
users (RACC) to validate inLane in terms of technical performance and user
acceptance.
Work carried out
towards its
objective
We have recorded several datasets in the first test-site, the Dutch A270 public
highway. We have used these datasets for conducting “record & replay” kind of
tests on all software modules. In addition, field tests were run on the city of
Eindhoven to test the lane-level navigation application using a tablet for
visualizing the HMI.
Regarding the Barcelona tests, ACASA and Barcelona City Council have
provided a recording of the region containing synchronized LiDAR, GPS and
camera data. We are currently analysing the feasibility of using this recording for
validating some of the inLane components and to plan the end-user tests.
9
Objective 9 To implement a long term (6 months) data collection pilot in real environment
conditions involving end users to test the system in its final configuration under
the expected range of environmental conditions in which it will be expected to
operate once is commercialised. The tests will be held on highways (suburban
scenario) and cities (urban scenario). Therefore, two main pilot sites will be used
the cities of Helmond and Eindhoven and the connecting roads A270 and N270
in the Netherlands as well as city of Barcelona and all the ring roads and
highways around it.
The pilots and demonstration will include end-user (RACC) and stakeholder
enrolment (ERTICO) to involve them in the project which will reduce the gap to
the market and enhance end user acceptance of the inLane products.
Work carried out
towards its
objective
We have recorded so far 2 TB of data in the city of Eindhoven, including the test
site between the cities of Helmond and Eindhoven. We expect to record more
datasets the following months. These datasets are being used for “record &
replay” tests that will be useful to validate the software before the pilot tests.
We also have a recording of the region of Barcelona (see progress on previous
objective) for the same purpose.
Objective 10 To disseminate the project results to both the scientific community and the end-
users (European drivers) and confirm the conditions for a successful business
model. The main focus will be to develop a marketing plan for rapid target
market penetration. With the help of ERTICO inLane will be promoted at
congresses, workshops and seminars.
Work carried out
towards its
objective
inLane has been disseminated through many channels during the first 18
months of the project. See a summary of dissemination activities on the
description of the work done on Task 6.2 (Scientific and Industrial
dissemination).
10
3.2 Explanation of the work carried out per WP
3.2.1 WP1: Requirements, specification and architecture definition
Work carried out plus contributions of each partner involved
The iterative process (specifications, prototyping) of inLane has been agreed on. The three prototype
iterations have been defined and build the basis of the inLane developments:
• Prototype 1 is a high-performance platform usable in the car for research but which does not
comply with automotive standards. For this prototype, PC like components that are already
available within the project team are used.
• Prototype 2 will unify the commonalities of the available platforms into one platform and
further required components will be added.
• Prototype 3 – the result of the inLane project – will be close to an embedded system and
usable in different cars. No product will be created within project lifetime but a roadmap from
inLane to an automotive product.
Task 1.1 Defining use-cases and test scenarios (VICOM, ERTICO, HRI, INTEL, TCA, TOMTOM,
TUE, ACASA, IMI)
A first set of use cases regarding map cartography updates for “cooperative lane navigation systems”
have been collected for the final inLane prototype.
Several datasets for laboratory tests have been recorded using RTMaps. Different traffic scenarios
and circumstances for field tests at the DITCM test site have been identified which involve:
• High-way scenarios
• Entry and exit ramp scenarios
• Traffic light stop-and-go scenarios
• Intersection crossing scenarios, including left, right, and full turns
• Dense traffic urban scenarios
• Tunnels with underground exits scenarios (not in DITCM)
• Low-visibility scenarios (potentially nigh-time, rain, fog, and snow).
The first versions of the system components are about to be evaluated in a unified manner. The
performance of the single modules has been tested. Results are described within WP4.
Task 1.2 Specifying system requirements (VICOM, ERTICO, HRI, INTEL, TCA, TOMTOM, TUE,
ACASA)
The primary system requirements have been specified which comprise positioning (including
accuracy), reaction time, navigation (including lane by lane navigation), user interface experience,
inputs against road safety and minimum alerts.
Task 1.3 Defining inLane architecture and interfaces (VICOM, HRI, INTEL, TCA, TOMTOM, TUE)
The general architecture that is targeted for the inLane system within the developments in the
different prototype stages has been defined. At this point in time, one single platform is the aim of the
inLane end-to-end system. inLane hardware and software components that are considered for the
11
inLane system are described. The first versions of the system components are about to be evaluated
in a unified manner; the performance of the single modules has been tested. The technical system
specifications include – in addition to the general hardware and software components – the interfaces
between these components that are targeted for the inLane system within the developments in the
different prototype stages. Following hardware components are considered: GNSS receiver, IMU,
camera, CPU/GPU, communication modules and power supply. On the part of the software, data
structures have been defined and the software modules for position estimation, detection and
alignment, map and HMI have been detailed within this deliverable.
Task 1.4 Monitoring of architecture and interface compliance (VICOM, INTEL, TCA, TOMTOM,
TUE)
During the project’s life, the compliance to the defined architecture and interfaces will be monitored by
the Architecture Review Board. The ARB consists of one representative of each partner participating
in WP1 and is headed by the leader of the WP. At this stage of the project, no changes regarding
architecture or interfaces have been requested and filed to the project’s ARB.
Overview of the project results towards the objectives
Objective Project result
The further detailed definition of use-
cases and related test scenarios, which
will lead to functional requirements of the
system and which, in turn, will lead to a
technical specification of the system.
• Collection of first set of use cases regarding map
cartography updates for “cooperative lane navigation
systems”
• Recording of several datasets for laboratory tests
• Identification of different traffic scenarios and
circumstances for field tests at DITCM test site
• Evaluation of first versions of system components in a
unified manner
• Specification of primary system requirements
The further and detailed design of the
architecture of the hardware and software
components of the project, on basis of the
system’s technical specifications,
including all interfaces between the
components, while considering existing
platforms and standards.
• Definition of general architecture targeted for the
inLane system within developments in different
prototype stages
• Description of inLane hardware and software
components considered for the inLane system
• Technical system specifications include
o General hardware and software components
o Interfaces between these components
The monitoring of the compliance to the
defined architecture and interfaces during
the project lifespan. This is performed by
the project’s Architecture Review Board
(ARB).
• ARB consists of one representative of each partner
participating in WP1 and is headed by the leader of
the WP
• No changes regarding architecture or interfaces have
been requested and filed to the project’s ARB by now
12
Next steps:
• Revision of use cases
o Specification of end-user related use cases in more detail (along with ongoing
development and more exact information about output of next prototype)
• Update of test scenarios for the next test phase
• Revision of functional system requirements for next prototype stage
• Update of description of hardware components used within next prototype version (one
unified platform)
• Revision of software module descriptions
• Update of HW and SW interfaces including their implementation status
Deliverables
D1.1: Requirements, Specifications, and Architecture document
This deliverable describes the functional requirements of the inLane platform and pre-commercial
product, their technical specifications, and the inLane architecture and interface descriptions. This
document will be available at the end of the M3 month of the project and it will be adjusted
incrementally (M12/ M24).
# Title Due Date Status
D1.1 Requirements, Specifications, and Architecture document v0 M3 Completed
D1.1 Requirements, Specifications, and Architecture document v1 M12 Completed
D1.2 Requirements, Specifications, and Architecture document v2 M24 Upcoming
Milestones
# Title Due Date Status
MS2 inLane requirements, specifications and architecture delivery M3 Completed
13
3.2.2 WP2: GNSS and vision-based road and scene element
geolocalisation and characterisation
Work carried out plus contributions of each partner involved
Task 2.1 EGNSS data treatment for enhanced position calculation
A multi-system GNSS positioning module based on pseudo-range and Doppler observations has
been developed by TCA. The GPS observations are corrected using EGNOS data (slow and fast
corrections, ionospheric model). The EGNOS information is received via EDAS (c.f. task 2.6). The
observation data of the other systems are corrected using their respective standard models using
data from their navigation messages. The GNSS data processing algorithms are implemented in the
sensor data fusion module where its output is used for position estimation.
The observation data are received from a multi-constellation GNSS receiver, being able to track
European GNSS signals from Galileo and EGNOS as well as GPS and GLONASS. The hardware
interface has been established for getting observation data as well as navigation data for real-time
operation. The GNSS observation data are made available via a software module to the sensor data
fusion component. The work on integrity computation has not started yet.
Task 2.2 Design and development of vision-based lane-level road parameter estimation
In this task, VICOM developed a module that is able to detect lane markings in the scene, and to fit a
multi-lane model, where each lane is modelled as a second order curvature in the road-plane. The
method is designed to work well in highway scenarios, under the hypothesis that lane markings exist
and are visible. A calibration file is required, which determines the intrinsic parameters of the camera,
and the relative position and rotation of the camera with respect to the world coordinate system. The
algorithm is implemented as a RTMaps component.
Preliminary evaluation activities have shown good results of the algorithm under the defined
assumptions, and very high efficiency in terms of computational load. Currently, VICOM is discussing
with HRI how to adapt the lane detection module to serve as an input to the camera to map alignment
module.
Task 2.3 Design and development of vision-based traffic sign detection and recognition
algorithms
VICOM developed an alpha version of The Traffic Sign Recognition (TSR) module, which uses
monocular images as input, and it is able to detect, track, and classify into adequate categories the
traffic signs present in the scene. For this version, we have focused on speed limit signs. Additionally,
image localization is used to estimate the real-world localization of traffic signs with respect to the
camera. The algorithm is implemented as a RTMaps component.
An AlexNet based traffic sign detection and recognition network trained using Caffe and provided by
Vicomtech is being ported over by INTEL to use Intel®’s clDNN library for inferencing on Intel®’s
Graphic architecture. clDNN is an open source neural network targeted C++ library which makes use
of OpenCL under the hood, with optimized layers for Intel® Graphics architecture. The goal is to
investigate the feasibility of running it in real-time and prove the efficiency of the integrated graphics
for low-power inferencing, allowing future neural networks to run on highly efficient architectures.
14
Task 2.4 Design and development of vision-based relative localization algorithms and map
matching algorithms for absolute localization
TUE has developed extended Alpha version for D2.9 vision-based relative localisation (visual
Odometry) and D2.10 Software modules for creating and updating maps from crowdsourced data
(SLAM). The components that are developed are visualized below, together with existing components
and components that are developed in parallel projects. Work includes software design and
engineering, camera hardware design and engineering, and integration of the results in the test
vehicle.
Figure 1: Components for creating and updating lane-level accurate maps from crowdsourced data. Existing
components (black), components developed in inLane (green) and components developed in parallel projects
(red).
As part of D2.9 Vision-based Software modules for local map matching and GNSS fusion v1. TUE
has ported their visual odometry module to RTMAPS and developed an automotive spec. stereo
camera and accompanying RTMAPS driver. Furthermore, the following improvements are realized:
• Advanced automatic key-framing to improve accuracy and stability.
• Fully multi-threaded pipeline to improve throughput (frames per second).
• Modular software architecture compatible with RTMAPS.
• Dead reckoning and delay compensation.
As part of D.10 Software modules for creating and updating lane-level accurate maps on basis of
crowdsourced local map data, TUE has updated its COP-SLAM optimization framework and is
currently developing an end-to-end framework for crowd sourcing map data and creating/updating the
maps on a back-office using SLAM algorithms. The results of Visual Odometry and SLAM are
visualized below. This work is mainly carried out by TUE in strong cooperation with TomTom.
Figure 2: Output of TUE Visual odometry (middle) and SLAM optimization (right) and GPS ground truth (left).
15
Task 2.5 Sensor Fusion
For fusing the sensor data a Kalman filter software module has been developed. The vehicle’s
position is estimated using the data from a GNSS receiver, a Visual Odometry algorithm and an
inertial measurement unit. The underlying state space model as well as the measurement models for
every sensor were developed. The new models for the visual odometry data use the full information
and avoid computing derived quantities. The Kalman filter has been implemented in C++ and has
been wrapped in an RTmaps software module. The interfaces to the sensors have been established.
The module is developed to processes the incoming sensor data in a correct timely sequence.
The sensor data module is available as RTMaps software component and ready for integration tests.
The performance of the positioning needs further tuning for reaching lane-level accuracy in a variety
of scenarios. First accuracy investigations show that we reach lane-level accuracy in clear sky and
rural scenarios. Real urban scenarios have to be further investigated to get insights into the optimal
tuning of the fusion algorithms. The key for further improvements will be to optimize the selection of
accurate GNSS observations from the set of all observations which may have large amount of
measurements negatively affected by multipath.
This work has been led by TCA. In parallel, Intel® is currently investigating the feasibility of integrating
its own Wireless-GNSS 2x00 receiver, which relies on a specific daemon in Linux. A possible
interfacing between the daemon and the RTMaps tool would allow Intel to develop an RTMaps
component for its own Wireless-GNSS 2x00 receiver and both ease and accelerate its integration in
designs requiring multi-constellation compatible receivers with high precision in sensor fusion
modules.
Task 2.6 Communication Module and Protocols
• Communication between the EDAS server and inLane positioning module (3G, 4G):
An EDAS service level 0 client has been implemented, which receives the EGNOS messages
via internet. The SISNeT protocol is used for the transmission of the data. The EGNOS
messages are decoded before forwarding the information to the GNSS processing software.
The next step is to wrap the EDAS client in an RTmaps module to be ready for real-time
operation.
This work has been led by TCA.
• Communication between inLane positioning module and cloud infrastructure (3G, 4G):
One of the main objectives of the inLane project is to update an existing map based on in-car
observations.
In order to facilitate the communication of in-car observations by the perception system to the
outside world, an initial version of an RTMaps module has been developed that allows for
uploading of observation data to a back office. In this particular case, this module aims at
sending traffic sign observations to the back office. This allows to exploit an existing TomTom
implementation providing functionality for browsing of historical data and clustering of
observations, both to improve on the classification confidence as well as the estimated
position. The component is responsible of collecting traffic sign observation data, position
data at the time of observation as well as the formatting of the collected data in JSON format
such that the data is self-descriptive. The actual uploading of the data is then performed using
HTTP posts.
Next steps include the further integration with the developed traffic sign recognition module
(Task 2.3) and system testing.
This work has been led by Tom Tom.
16
• Communication between mobile phone and inLane positioning module (WiFi or Bluetooth):
Within TomTom, a navigation application has been developed that is capable of rendering
lane-level geometry, as defined in the TomTom High Definition map, in its HMI and to provide
the user with lane-level advice. In turn, the application requires lane-level accurate positioning
of the ego vehicle for its correct functioning.
In order to provide the navigation application with position data as estimated by the
positioning sub-system, an RTMaps component has been developed that uses a TomTom
proprietary Remote Procedure Call frame work to send position data to the navigation
application.
The navigation application runs on an NVIDIA Shield tablet and has been configured such
that conventional map-matching is disabled, as it is assumed that this is one of the tasks of
the positioning sub-system. Providing position updates by an external system has been
successfully tested using both an x86 platform as well as an NVIDIA DRIVE PX2 system.
Task 2.7 Lane-level road model representation
In this reporting period, we have now fixed the representation of the road representation on lane, half-
road and road level. The representation contains similar elements to the NDS-standard. Furthermore,
our enhancement pipeline now allows for correction of small errors such as incorrect lane width.
This task has been led by HRI.
Task 2.8 Module for map-to-sensor alignment of road information
Regarding the camera-to-map alignment, alternative algorithms have been exploited. Apart from
additional feature detection algorithms, also a deep learning approach was tested. On the one hand,
we used deep learning in order to perform image segmentation on the camera output. The alignment
was done by comparing the segmented road area with rendered virtual street views. In this case, not
only road boundaries but the whole road area was rendered. On the other hand, we used deep
learning to detect lane boundaries. In this case, deep learning was used to replace the canny edge
step of the original approach.
Furthermore, we are currently preparing an alternative approach with the aim to process lane
information provided by Vicomtech’s lane detection module. By doing so, the performance of the
alignment algorithm as well as the consistency of the modules may be improved.
This task has been led by HRI.
Task 2.9 Local Dynamic Map specification and implementation
In this reporting period, we finished the implementation of the first version of the static level. The
result is a server side implementation that can be used from every module. One of the major outputs
is the birds-eye view visualization which displays the static map content, respectively the map
geometry. Furthermore, it is under discussion in which ways this visualization can be fused with the
output of the position estimation module.
Currently, we work on the import and retrieval of further information as e.g. the driven path or
curvature which will be required for future tasks such as the display of possible paths or other
dynamic information.
This task has been led by HRI.
17
Overview of the project results towards the objectives
Objective Project result
To reach, with EGNSS data processing filters
on the one hand and the use of video
localisation systems on the other hand, a sub
meter positioning accuracy while making use of
low-cost (mass market) GNSS equipment
(EGNOS/GPS with EDAS capability in the short-
term and GPS/Galileo in the future).
First accuracy investigations show that we reach
lane-level accuracy in clear sky and rural
scenarios. Real urban scenarios have to be
further investigated to get insights into the optimal
tuning of the fusion algorithms.
To develop software modules for road modeling
using preferably single camera set-ups. More
specifically, this means i) lane modeling
methods will be developed, studying the
feasibility of generating a holistic lane-level
model of the road with information about
number of lanes, geometry, type of lane, etc. ii)
traffic sign identification will be carried out to
determine the traffic rules in force at each
location and iii) vehicle position calculation
related to lane-level and road-level will be used
as a positioning sensor that can be fused with
the GNSS position data.
The first version of these software modules was
developed by month 12 and reported on
deliverable D2.3. Software deliverable
corresponds to D2.7.
To fuse the input data provided by the above
mentioned sensors for i) calculating precise
localisation of the vehicle in terms of absolute
positioning and in terms of in lane and road
positioning, ii) calculating lane by lane
navigation instruction based on positioning and
road modeling and iii) generating information for
updating maps in real time.
The first versions of these software modules were
developed by month 12 and reported on
deliverables D2.1 and D2.5. Software deliverables
correspond to D2.9 and D2.10.
To define communication channels and
protocols for exchanging real time cartography
information
As explained before, an initial version of the
communication channels was defined in Task 2.6.
The following deliverables were generated during this reporting period:
• D2.1: Report on developed software modules that fuse EGNOS-GNSS absolute position
estimates, IMU relative positions estimates, and vision-based (map matching) absolute
position estimates. V1. (Report)
• D2.3: Report on developed vision-based software modules v1 (Report)
• D2.5: Report on sensor-to-map data alignment v1 (Report)
• D2.7: Vision-based software modules for road road/scene identification v1 (SW)
• D2.9: Software modules for local map matching and GNSS fusion v1 (SW)
• D2.10: Software modules for creating and updating lane-level accurate maps on basis of
crowdsourced local map data v1 (SW)
18
How results can/will be exploited
Exploitable result Exploitation potential
Data fusion for enhanced
position estimation
Knowledge about vision-aided GNSS positioning and models/
software for vison-aided lane-level positioning can are the basis for
new product development or integration in existing software
products.
Intel® is analysing the possibility of using its Intel® Wireless-GNSS
2x00 receiver in the RTMaps integration framework to expand its
reach in the automotive sector.
Vision-based lane detection Vision-based lane detection is usually employed on driver
assistance applications such as lane departure warning. It is
normally implemented in cars, buses and trucks, but there is also
an exploitation potential in airplanes, where the land operations
could also be assisted. This last scenario is still to be exploited.
Vision-based traffic sign
recognition
Intel® is interested in computer vision and neural network based
workloads running on Intel® Graphics in order to better understand
the applicability and feasibility of efficient inferencing in an
automotive setting. The traffic sign recognition use-case is a
standard use-case which is the foundation of all ADAS visual
systems today. As such it’s an important workload to tailor fit for
Intel® Graphics.
Visual Odometry As the previous cases, the Visual Odometry algorithm is used in
many applications of autonomous driving, so it has a big
exploitation potential.
Camera to map alignment C2MA allows an improved self-localization as well as an improved
relative localization of other traffic participants relative to the map
geometry. This is useful for improved prediction models and future
risk estimation. Application use cases for future exploitation:
Generalized intersection warning assistant, predictive risk warning
for highway merge and overtaking.
Local Dynamic Map calculation An improved representation of lane and road geometry including
road boundaries and drivable path allows an extraction and
prediction of the ego- and other cars trajectories with increased
detail. This is useful for improved prediction models and future risk
estimation. Application use cases for future exploitation:
Generalized intersection warning assistant, predictive risk warning
for highway merge and overtaking.
19
3.2.3 WP3: Applications: Crowdsourcing enhanced map generation in real
time and lane-level navigation
Work carried out plus contributions of each partner involved
T3.1 Lane-Based Navigation Algorithm
This task aims to develop the algorithms necessary for the D3.3-D3.4 Lane level navigation
application for Android. Extended Alpha version are currently available (see section on D3.3-D3.4 ).
This task is mainly carried out by TomTom with the other partners providing inputs required for
coordination of the integration with other inLane module. TUE is responsible for the alignment and
integration in the test vehicle.
T3.2 GIS Data Aggregation Algorithm
This task aims to update map data from crowd sourced inputs. Currently the focus is on improving
and updating traffic sign locations and types. This task focusses on the back-office where updates are
processed. This task is mainly carried out by TomTom with the other partners providing inputs
required for coordination of the integration with other inLane module. TUE is responsible for the
alignment and integration in the test vehicle. Furthermore, TUE is developing SLAM algorithms that
allow creating and updating of 3D-Lane Map Layers, see also section on (see section on D3.3-D3.4 ).
T3.3 Lane-Accurate Road Model Definition, Database and Data Update
This task aims to develop the map data (models, standard, databases) necessary for the D3.3-D3.4
Lane level navigation application for Android. Extended Alpha version are currently available (see
section on D3.3-D3.4). This task is mainly carried out by TomTom with the other partners providing
inputs required for coordination of the integration with other inLane module. TUE is responsible for the
alignment and integration in the test vehicle.
T3.4 User-Compiled GIS Information
Currently the focus is on sending traffic-sign updates from the back office to the navigation device.
This work is carried out by Vicomtech (delivering traffic sign detections), TomTom (aggregating the
traffic sign detections in a back office and sensing updates back to the navigations devices, and TUE
(for support with the test vehicle).
20
Figure 3: visualization of the traffic sign detection on the navigation device and the aggregated information in the
back-office.
Overview of the project results towards the objectives
This section describes the deliverable of this work package. Please note that some deliverables have
two incremental version.
D3.1-D3.2 Report on Lane level Navigation application and enhanced maps.
Status: D3.1 completed
Details: D3.1 Report on Lane level Navigation application and enhanced maps v1.0.docx/pdf
Summary:
The report describes the work carried out in Work package 3. It describes the deliverables D3.3, D3.5,
and D3.7.
D3.3-D3.4 Lane level navigation application for Android
Status: D3.4 completed
Details: D3.3_Lane_level_navigation_application_for_Android_v1.docx/pdf
Summary:
An extended Alpha version of the Lane-level navigation application has been developed. It runs on an
off-the-shelve tablet (NVidia shield) and provides users with lane-level accurate routing advice, see
the figure below. As an extension of the Alpha version, the Lane-level navigation application can be
fed with information from an RTMaps component, thereby allowing for integration with the Lane-level
accurate positioning modules of inLane. Currently, the tablet is being integrated in the test vehicle and
prepared for user trials.
21
Figure 4: 3D lane map presentation augmented with the lane plan (top) and the advice to change lane (bottom)
D3.5-D3.6 Enhanced map databases and SW
Status: D3.5 completed
Details: D3.5_Enhanced_map_databases_and_SW_v1.docx/pdf
Summary:
An extended Alpha version of the enhanced map database has been developed featuring a 3D Lane
Map layer and a Lateral depth off-set layer (aka. RoadDNA). The 3D-Lane Map Layer represents the
road geometry model as a set of topologically connected segments where every of these segments
consist of a group of lanes. The Lateral depth off-set layer encodes a depth map perpendicular to the
driving direction, see the figure below. This layer can be used for visualization purposes but also, to
be correlated to in-car point cloud observations for localization purposes. The access library for these
is layers is implemented in C++ and is MISRA-C++ compliant.
Figure 5: A visualization of the lateral depth off-set encoded in RoadDNA.
22
D3.7 SDK for interfacing to allow third parties to include their navigation application
Status: Work in progress
Details: D3.5_Enhanced_map_databases_and_SW_v1.docx/pdf
Summary:
The Enhanced map database engine is a component that uses the same interface to the application
as the commercial navigation engine. This allows third parties to use the commercially available SDK
of TomTom to apply the navigation engine. Currently, this SDK is made available to the inLane
partners via the developer’s portal of TomTom to build experience with the interfaces. In a next step,
the lane navigation engine will be made available via this portal enabling inLane partners to build their
own lane navigation experiments.
How results can/will be exploited
The 3D-Lane Map Layer is currently in the process of being commercialized by TomTom. In parallel
work, a streaming map engine is developed to stream map content, including 3D Lane-map Layers,
and updates to TomTom devices.
23
3.2.4 WP4: Integration and testing
Work carried out plus contributions of each partner involved
Task 4.1 Definition of methodology
The methodology was defined in deliverable D4.1, considering EN 16803. The main contributors were
VICOM and TCA. However, the rest of the task participants also participated in the discussions in
previous face to face meetings and conference calls. The documentation of the methodology (D4.1)
has four main sections:
• General Strategy (Continuous Integration approach)
• Development
• Software integration and testing
• Performance assessment methodology
Currently, the consortium is following the defined methodology and collecting suggestions for
improving it. The final version of the methodology will be delivered at the end of the project.
Task 4.2 Integration of the prototypes
As explained in the deliverable D4.1, we believe that development, integration and evaluation stages
are not completely decoupled. So, same of the work carried out in this work package feeds both Task
4.2 and Task 4.3.
TUE configured a vehicle for integrating and testing the algorithms. The following figures describe the
installed sensors.
Figure 6 Test vehicle (lateral)
24
Figure 7 Test vehicle (front)
Using these vehicle, several datasets were recorded for laboratory tests.
Following the methodology defined in T4.1, VICOM configured the software framework to enable
Continuous Integration. Therefore, VICOM configured an instance in Amazon EC2 with Ubuntu 16.04,
GitLab, RTMaps and Docker.
As defined in T4.1, there is common Docker image that contains the dependencies of all software
modules. All source files required to build this image (Dockerfile, etc) are stored in a project in GitLab.
Each time someone adds a new dependency to the Dockerfile, an automatic built is triggered, and a
new docker image is generated. This new image is pushed to the Docker Registry configured in
GitLab and it is available for testing the inLane software modules. Partners can also download this
Docker files and build the image locally.
Figure 8 Docker image project in inLane's GitLab
25
Figure 9 Automatic build of the Docker image
All software developers worked on porting the software modules to RTMaps, which is the selected
integration middleware (see D4.1). The software modules implemented in RTMaps are currently
available in inLane’s GitLab, which serves as version control system.
Figure 10 inLane's Git repository (GitLab)
26
After some discussions, the participants in this work package decided to integrate 4 demonstrators
during this reporting period. Each of these demonstrators is focused on one of the inLane’s core
functionalities:
• Demo for assessing positioning accuracy
• Demo for showing camera to map alignment and Local Dynamic Map functionalities
• Demo for showing lane-level navigation functionality
• Demo for showing map update functionality
Task 4.3 Evaluation of the prototype
Three software testing level were defined:
• Unit tests: used to test software modules individually.
• Integration tests: individual software modules are incrementally combined and tested as a
group.
• End-to-end system tests: once the modules are integrated, the completely integrated
system is tested end to end with the objective of ensuring that it meets the defined
requirements.
These software testing levels are usually represented in a pyramid (see Figure 11). The bulk of the
tests are unit tests at the bottom of the pyramid. As you move up the pyramid, the tests gets larger,
but at the same time the number of tests (the width of the pyramid) gets smaller. Figure 11 Test
pyramid
Figure 11 Test pyramid
During this reporting period, the vast majority of tests were unit tests. The results obtained during the
first 12 months are summarised in D4.1. Then, we conducted several integration tests and finally
some end-to-end system tests for the 4 demos defined in T4.2. This approach is in line with
Continuous Integration philosophy. The idea is to minimise the costly end-to-end system tests, testing
comprehensively each software module. All participants in T4.3 contributed to the evaluation of the
prototypes.
27
Overview of the project results towards the objectives
The main objective of this Work Package is to integrate and validate the components of the inLane
system, verifying the interoperability between the architectural components and the existing network/
services environments. Furthermore, in this WP functional tests and performance measurements for
the operational verification will be conducted. In this sense, this work package has achieved these
objectives for the reporting period, validating the software components of the initial prototype and
integrating them in several demonstrators.
The following deliverables were generated during this reporting period:
• D4.1: Report on Prototype Integration, Validation and Testing Protocols v1
• D4.3: Prototype 1
The following milestone was achieved:
• MS3: inLane subsystems delivery for the first prototype & First prototype phase demonstrator
trials
How results can/will be exploited
The outputs generated in this reporting period could be exploited on two main sectors:
• Driver assistance or autonomous driving: having an accurate positioning together with the
generation of a Local Dynamic Map is essential in autonomous driving and really valuable to
generate advanced driver assistance systems.
• Navigation: lane-level navigation with crowdsourced map updates can significantly enhance
current navigation systems.
Sections corresponding to WP2 and WP3 give more details about the exploitation of each software
module.
28
3.2.5 WP5: Lane-level guidance pilot – user
Work carried out plus contributions of each partner involved
Task 5.1: Definition of methodology
The second phase test will be carried out at the end of 2017 and will test the Prototype 2 of the
inLane solution. This second prototype will unify the commonalities of the available platforms into one
platform and further required components will be added. This will be done probably in DITCM with
expert users, and in Barcelona.
During the reporting period ACASA has requested, selected and distributed to the technical partners a
cloud points map of the Barcelona area from the Government of Catalonia. This map will allow
comparing the information gathered during the test to improve recognition algorithms of the inLane
solution.
Once obtained the cloud points map from the Catalonia government, ACASA and IMI are in contact
with the competent administration (Servei català de Transit) to understand and fulfil the requirements
from them to consent the test.
Task 5.2: Site system integration &Task 5.3 Test & demonstration with end-users
First phase test
During the first development cycle, technical expert users from TUE and Tom Tom recorded several
datasets in the DITCM test scenario to test the modules of the first prototype. All data has been
recorded using RTMAPS and then processed off-line. Limited on-line experiments have been
performed with existing pre-commercial technology (i.e. the basis for the technology developed in
inLane). The conclusion is that additional map info is required to achieve a product-viable lane-based
navigation concept
User survey
In order to involve the user point of view in an early stage of the project a survey has been designed
planned and executed.
The survey has been designed among the user experience experts of TomTom, VICOM and ACASA.
To carry out this survey an online questionnaire has been used. This questionnaire has the main
objective to understand the barriers and the level of acceptance of the future inLane solution among
potential users. Besides the questionnaire also pursue to understand the knowledge of the user of the
GNSS systems.
The questionnaire has been disseminated trough the channels of communication of ACASA as well
as the rest ones of the rest of the partners. The network ERTICO has been used as well to
disseminate the survey.
In order to attract more participants a gamification process has been used: a TomTom personal
navigation device (EG: TomTom GO 520) has been raffled among the participants.
The survey has obtained a big impact: 910 answers have been obtained and a first report analysing
the results has been produced by ACASA.
29
Overview of the project results towards the objectives
The main objective of this WP is to test and evaluate with large and real pilots the inLane solution in
real conditions and to assess users’ satisfaction. As expected the technical development has not
produced so far, an integrated prototype available to be tested by real-end users. Therefore, as
planned, the main effort of this WP during the reported times has been to feed the development of the
inLane solution paving the road of the final test with real users in real conditions that will be carried
out in Barcelona at the end of the project.
How results can/will be exploited
The results obtained so far of this WP will be exploited as follows:
CLOUD POINTS MAP: it will be used to test the second prototype to compare the information
gathered during the test in order to improve recognition algorithms of the inLane solution.
PHASE ONE TEST: inLane project has an iterative approach. Therefore, the results of the test of the
first prototype will determine the next steps in the technical development of the solution.
USER SURVEY: it will directly feed the technical development of the inLane solution (WP1).
30
3.2.6 WP6: Dissemination and exploitation
Work carried out plus contributions of each partner involved
Task 6.1 Dissemination plan
ERT proceed with an analysis of the project under its different angles in order to provide the most
appropriate marketing material and the dissemination strategy. ERT has developed the dissemination
strategy in cooperation with VICOM and TCA, who assessed the suitability of the visual identities with
regards to the objectives, activities and expected outreaches of inLane. The dissemination strategy
was also aligned with the GSA communication strategy.
The work on the dissemination strategy included also the development of the marketing material,
including the visual identitiy and the website. Based on the visual identity, an initial web site was
developed with a generic content and the required sections for the projects (About, News, event,
Library).
Several options were developed for the visual identities and the web site, prior to the kick off meeting.
Therefore the Kick-Off meeting was used by ERT to present the dissemination different options for the
logos and the web site structure. This presentation at the Kick-Off meeting and the consultation of the
inLane beneficiary led to agree about the final options for the project logos and the web site structure.
The agreed visual identities and the initial web site allowed to launch the web site publication, start
the social media presence and develop the first project brochure.
The communication strategy and the dissemination plan were further developed by ERT in
cooperartion with VICOM and TCA, as part of a single deliverable. Beyond delivering the project
visual identity, ERT developed on overview of the dissemination strategy, listed the different
dissemination channels and the presented the communicatio tools in the document.
Task 6.2 Scientific and Industrial dissemination
The consortium partners carried out scientific and industrial dissemination activities in a various ways:
publications, proactive cooperation with ongoing projects, project presenations at conferences, online
publications, etc.
In the first 18 months, consortium partners organised and/or attended over 10 high-level conferences,
congresses and events including ITS European and World Congresses, Open Auto Drive Forum,
SaPPART Conferences, European Space Solutions 2016, H2020 Space Information Days, IEEE
ITSC 2016 and EU GNSS missions.
ERT, VICOM, INTEL and IMI also presented papers, participated in panel discussions and special
interest sessions on project progress and results at various conferences and workshops. VICOM
provided Scientific publications including an entry in the ‘IET Intelligent Transport Systems’ journal.
All inLane projects activities and events were also publicised online. The audience for these activities
included automotive industry, map providers, ITS suppliers, telecom industry, road authorities and
operators, European institutions, standardisation bodies, European projects dealing with positioning
and mapping, test laboratories and research organisations.
31
Task 6.3 Exploitation plan
ERT and VICOM have analysed the market to be addressed by the inLane beneficiaries, as well as
the inLane value proposition, vision and mission.
Following this analysis, ERT and VICOM have developed a methodology and a basis to elaborate the
business and exploitation plan during the lifetime of the project. ERT and VICOM drafted the intial
exploitaton plan in the the delievrable D6.6 - Business and exploitation plan v1. In the initial
exploitation plan, ERT and VICOM developed the research process to be followed, in order to define
the business and exploitation plan during the second period of the project.
HRI, TOMTOM, INTEL and TUE contributed to the initiial exploitation plan with inputs identifying the
potential business models for the exploitation of different outputs of inLane project results, looking
forward achieving a global impact and a market inside and outside the European borders.
Task 6.4 Standardisation
IFSTTAR apporached the SaPPART COST action to raise standardisation issues in positioning for
Ithe Inlalne Lane Level navigation application. Therefore the first step consisted to verify that the
requirements of the current CEN/CENELEC EN 16803-1 [Definitions and system engineering
procedures for the establishment and assessment of performances] standard release is actually
applied by inLane, in particular in the context of the work package 4.
As a result of the analysis of the EN 16803-1, IFSTTAR also started to consider to update the test
procedures to take into account a positioning process using an hybridisation of GNSS and Computer
vision.
Task 6.5 IPR and protection of results
The work carried out within inLane as part of Task 6.5 with regards to the different protection
mechanisms and details about the license types that will be used in the deployment and exploitation
of inLane are described in this deliverable D6.8 Report on protection and use of IPR, and is an on-
going process that will continue until the end of the project. In Month 30 Deliverable D6.7 Final
Business and Exploitation Report will provide candidate plans for the exploitation of inLane as a
service, technology, product via a partner business unit, or indeed, as a spin-off company.
inLane is actively monitoring the creation of IPR during the lifetime of the project. As part of this
process Results which are both jointly and individually owned will be identified. Proposals for the
division of share of such results and the base conditions for their exploitation were made by the
research team. These proposals will be made in line with the conditions first set out in the Consortium
Agreement and in function of the IPR audits being conducted periodically during the project, with the
support of an IPR officer.
32
Overview of the project results towards the objectives
During the reporting period, WP6 provided the project visual identity, published the web site and
launch the socialmedias (Facebook, Twitter and Linkedin) all linked with the web site and the ERTICO
socila medias. These results are formalised in the deliverables: D6.3 - Marketing Materials and D6.1 -
Analysis of strategic communication priorities and Dissemination Plan v1.
inLane participated in numerous events, conferences and workshops by way of presentations, panel
discussions, stand displays. Ten major events were covered. A complete report on the scientific and
industrial dissemination activities online as well at face-to-face events was provided in deliverable
D6.4 - Report of Annual Dissemination Activities.
EN16803-1 was acknowledge as the applicable standard for performance assessment by the relevant
inLane beneficiaries (mainly in the WP4) and the the specific testing issues for an hybrid GNSS and
computer vision system have been presented to the relevant standardisation body (CEN TC 5 WG1).
The inittial exploitation plan was provided as part of the deliverable D6.6 - Business and exploitation
plan v1.
Summary of the deliverables completed and uploaded during the reporting period:
• D6.1 - Analysis of strategic communication priorities and Dissemination Plan v1
• D6.3 - Marketing Materials
• D6.4 - Report of annual dissemination activities v1
• D6.6 - Business and exploitation plan v1
• D6.8 - Report on protection and use of foreground IPR
33
3.2.7 WP7: Management
Work carried out plus contributions of each partner involved
The inLane project contains contributions from different partners and many individual activities that
require close coordination to ensure that project milestones are satisfactorily achieved. The
management activities are comprised under WP7 with the following goals during the period:
• To achieve the objectives for the third period of the project in a cost-effective manner within
the agreed time scale.
• To ensure that the project is conducted in accordance with any contractual agreement
between the Consortium and the EC, and to maintain a continuous link with the GSA.
• To coordinate the work and to ensure effective communication between partners.
Thus, the principal objective within the first reporting period (month 1 to month 18) has been to
manage and coordinate efforts among all the partners to ensure the effective implementation of the
project, timely delivery of deliverables, as well as the adequate dissemination of results. The
management of the relations and the communication with the consortium partners, the European
Commission, and any other stakeholder external to the project, are principal responsibilities of WP7.
The Technical Coordinator has taken the following actions to monitor the project and assure that the
project is carried out as planned:
• Weekly conference calls focused on tracking the progress of technical work packages (WP1,
WP2, WP3, WP4 and WP5). The conference calls are scheduled on Mondays at 11:30
CET/CEST and have a duration of around 1 hour. The minutes are uploaded to inLane’s
workspace in Podio.
• Dedicated conference calls are also scheduled on demand. Only partners involved in the
discussed issue attend these meeting.
• A mailing list dedicated to WP4 is used for sending relevant information to all partners
involved in integration and testing.
• A Slack team (workspace), https://inlanedevelopment.slack.com/, was setup to improve
communication among developers.
Figure 12 Slack statistics for inLane
34
Overview of the project results towards the objectives
A more detailed description of the activities and management procedures carried out during the
project (including financial reporting, the explanation of the use of the resources and financial
statements) will be included in the Periodic Report that will be submitted within 60 days after the end
of the reporting period.
Summary of the deliverables completed and uploaded during the reporting period:
• D7.1 – Project management plan
• D7.2 – Project operating, quality and risk procedures
• D7.3 – Periodic Report
• D7.5 – Innovation management and compliance report plan v1
• D7.7 – Quality Assurance Plan
• D7.8 – Data management plan v1
• D7.10 – External Advisory Board reports v1
35
4. Conclusions
The project is progressing without major deviations and all the milestones and deliverables planned
for the first reporting period have been achieved. The present document has summarised this
progress, detailing the work carried out by the beneficiaries during the first 18 months of the project.
The document has followed a similar approach to the template of the Part B of the periodic technical
report. However, the final periodic technical report together with the periodic financial report will
delivered within 60 days following the end of this periodic report.
Another technical report (D7.3) will be submitted at the end of the project, M30, prior to the
preparation of the second periodic report and the project final report.
