inFuse

h1. 01/23 - Discussion on PoM 

*Participants:* 

Quentin, Simon

*Goal of the meeting:* Discuss the general state of the processing we want to showcase in sprint 1 and more precisely the problems we might encounter on PoM.

h2. General chain discussion

Ellon and I have been working on providing the right types of data to the DEM module. At the moment the chain from MORSE to the DEM module looks like this:

!existing_chain.png!

With:

* *Fake velodyne*: take as input the pointclouds produced by velodyne, aggregates them into one point cloud, and associate the pose of the robot to it.

* *Point cloud pose stamped* is a data structure defined in IDL for genom3 module from which we can build the DEM

ATM: *No POM*. What we would like is the following :

!wanted_chain.png!

This includes:

* *Changing fake velodyne* : makes it quite a bit harder as this means Ellon needs to "rewrite TF" and keep changes in pose in memory in order to aggregate properly when the robot moves

* *Decide how we stamp the data*: right now, the "pose" data structure from genom3 IS NOT attached to a reference frame. The reference frame is implicit (one frame world in which the pose is described). This is not going to be enough in the future, but requires quite some changes into PoM. So for the moment we consider only the following frames: world (absolute), robot (moving), and sensor (fixed to the robot). The PC will be expressed in the robot frame of reference, while the pose will be expressed in the world frame of reference. => THIS WILL CHANGE IN THE FUTURE

h2. PoM discussion

The main problem with PoM is how to get data in the past. Basically, when DEM is running there are 3 main participants in the interaction : 

* PoM: handles Poses

* DEM: builds the elevation maps

* Supervisor S: makes request such as "build the fused map between time t1 and t2 in the past"

*Question*: when the supervisor wants to make a request, how should it address it? and to whom?

---

The intuitive way is : 

* S addresses DEM with arguments t1 and t2 (e.g. floats) to trigger the function producing the fusion ==> *POSSIBLE IN GENOM*

* DEM addresses PoM with arguments t1 and t2 (same) to trigger a function in PoM to transfer the poses available between those time ==> *NOT POSSIBLE NATIVELY IN GENOM*

* PoM transfer data to DEM containing the poses (sequences of or_pose_estimator::state) ==> *POSSIBLE, BUT NOT THE WAY WE WANT IT (PUNCTUAL)*

* DEM builds the fused map with the given poses ==> *POSSIBLE*

Problem is two modules are not supposed to "speak sporadically together". The only way 2 modules can talk is through a port that is read at a given frequence by the receiver...

*At the moment, no real solution...*