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.

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:

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 :

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. Simon says: Not really ! Actually it is Quentin who needs to "rewrite TF" inside POM.
• Decide how we stamp the data: right now, the "pose" data structure from genom3 IS NOT attached to any specific 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

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", or "re-build the fused map in a given area (specified as spatial bounds".

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 Simon says: but the supervisor could send a request to POM, asking to export the poses between t1 and t2, and then send the request to DEM, asking to rebuilt the DEM between t1 and t2.
• 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... Simon says: modules are not necessarily periodic, they can handle asynchronous requests.
At the moment, no real solution...
This has to be worked out more thoroughly

---

Ellon says -> What is being implemented is this: