Project

General

Profile

0404 » History » Version 13

Quentin Labourey, 2018-04-04 16:37

1 1 Quentin Labourey
h1. 04/04
2
3
*Participants*:
4
* From MAG: Vincent, Fabrice, Clément, Raphaël
5
* From LAAS: Pierre, Ellon, Quentin
6
7
*Goals of the meeting:*
8 2 Quentin Labourey
* Integrate MAG Stereovision with LAAS DEM building
9
* Discuss Metadata addition to ASN.1 message
10
* Participate to the monthly progress teleconference
11
12
h2. Integrate MAG Stereovision with LAAS DEM building
13 3 Quentin Labourey
14
It took quite a while for MAG to be able to transfer Point clouds through the network: they had a problem with their docker and the way it was communicating with the world. They were able to provide an working point cloud and we could visualize it on Rviz thanks to Ellon's visualizer:
15 4 Quentin Labourey
16 5 Quentin Labourey
 
17
18 4 Quentin Labourey
!IMG_20180404_123749971.jpg!
19 5 Quentin Labourey
20
 
21 4 Quentin Labourey
22 6 Quentin Labourey
After some decoding problems, we could also produce a DEM and visualize it, but the data obtained did not make a lot of sense (pointclouds appearing in several unrelated places on the map while the robot was not moving). We did not have time to investigate the problem further to know if it came from the structure sent (pose attached) or from the DEM building algorithm.
23 4 Quentin Labourey
24
h2. Discuss Metadata addition to ASN.1 message
25
26 7 Quentin Labourey
The discussion mainly revolved around PoM and its interface and we did not actually get to discuss much about metadata:
27
* We introduced the genericTransform structure that was discussed last week. MAG seemed to be generally OK with this.
28 8 Quentin Labourey
* We underlined the fact it might be awkward to have several timestamps in the same message, e.g. in a PointCloud message: there would be the timestamp associated with the Point cloud data AND 2 timestamps associated with the genericTransform that has to come with it. Multiplication of timestamps should be avoided if possible.
29
* We discussed the need for additional services in PoM (such as parametrizing interpolation, asking for observation timestamps). At the moment, it seems that the functionalities that we defined are enough
30 9 Quentin Labourey
31
h2. Progress teleconference
32
33
The conference was a sum-up from each partner of their development progress:
34
* SpaceApps: repo maintaining + dfn integration on track. They are currently working on the orchestrator. 
35 10 Quentin Labourey
* Strathclyde: Several DFN already on the repo, unit tested + documentation on how to install CDFF properly. Romain said it should work for everybody without problems now. Raul underlined the fact the compilation of CDFF is DFKI's job and should be made via autoproj but SpaceApps said that different methods of compilation are not exclusive.
36 12 Quentin Labourey
* DFKI: Work on DFPC Common Interface, as well as the installation guide of CDFF_dev
37 10 Quentin Labourey
* MAG: Worked mainly on integration with us + RIDs for D5.*
38 11 Quentin Labourey
* LAAS: 5 tracks: 
39
** Integration with MAG in Simulation 
40
** Integration on Robots for LIDAR DEM
41
** PoM 
42
** Support of the repo and transfer of ready soft to CDFF repo. 
43
** Definition of proper types with metadata
44 13 Quentin Labourey
* DLR: Not present