inFuse

h1. Meeting to discuss more about PoM/Prism (a good one)

*Participants*:

Ellon, Pierre, Simon

 

*Goal of the meeting*: Discuss implementation details of PoM/Prism and try to take a decision about how to proceed (yes, again)

h2. Discussion

In this meeting we tried to define all the requirements for PoM, focusing on what is need to be done for the project and what is going to be done on this sprint. 

h3. PoM requirements

# *PoM has to provide most recent robot pose with respect to a given frame (e.g.: mission frame, site frame)*

  _Why_: Some clients need to know this pose in a high frequency (control, trajectory, velodyne, etc..)

  This pose is the fusion of the input poses produced by the various the localisation processes. It is produced synchronously (i.e. periodically) on a topic/poster. It is the pose of the robot base frame, with respect to a given frame, defined by a configuration request to POM. 

   

# *PoM has to provide the sensors poses with respect to the robot base frame for each living sensor, configured at start up.*

  _Why_: Because clients that exploit sensor data may need to know these poses to attach to the data

  The sensor poses to export are defined by configuration requests, that trigger or stop their emission. This way PoM will only output transformation from its internal tree to the sensors that are exploited, instead of publishing the complete tree each time. The output is synchronised with the most recent robot base frame pose (it has the same timestamp, so clients may associate them).

   

# *PoM has to gather all localisation information, as pose or delta-poses (increments)*

  _Why_: PoM need this information to fuse them so as to export the best robot frame pose

  PoM may accept complete poses or delta-poses. Some discussion about how to allow this happened, and the decision was to use a general type that allows to represent both poses and delta-poses (see below). These inputs are made through topics, similar to the way it's done on current pom-genom.

   

  +NOTE: Only one input will be implemented on sprint 4.+

   

# *PoM should provide a service where a client may request a pose between any pair of frames, at any pair of times*

  _Why_: because any frame may change in time, except the absolute world frame which is fixed once and for all.

  This request will mostly be used by DEM on this sprint.

   

# *PoM  has to gather information about internal joints of the robots, as poses only*

  _Why_: Because this is needed to update the internal tree of poses.

  The tree is loaded from a URDF file. The information about non-static joints/branches enters PoM through topics/ports published by mounts (or actuators), with the same data structure way it's done with localisation information.

   

# *PoM has to perform the fusion of the gathered localisation information*

  _Why_: This is needed to provide the best pose.

   

  +NOTE: This won't be implemented on sprint 4, in which a single localisation DFPC feeds POM+

   

# *PoM has to provide two services to let clients tell him which poses to memorise and which ones to forget*

  _Why_: So it can keep track of which poses may be updated in the future.

   

  +NOTE: This won't be implemented on sprint 4!+

   

# *PoM needs to manage an internal memory*

  _Why_: To allow the past pose updates while keeping the memory size under control

  The elements of the internal memory consists of: 1) a circular buffer buffer of a given size where all robot pose outputs are stored; 2) Counters to tell PoM if the poses will be kept after they go out of the time-span of the buffer; 3) A garbage collector that removes poses no one will ever ask.

   

  +NOTE: Only the internal buffer will be implemented on sprint 4.+

h3. Generic pose type

We decided to use a generic pose type. The pose will have something like:

* Frame ID 1

* Timestamp 1

* Frame ID 2

* Timestamp 2

* Pose

* Pose Covariance

This way we can represent Normal poses (same timestamp, different Frame IDs), delta-poses (same frame ID, different timestamps), or transforms between different frames at different times, e.g. "Transform from frame ID 1 at time 1 to frame ID 2 at time 2".

This should be proper documented, and Ellon thinks we may have some problems convincing others to use this structure.

h3. Metadata tagging

* Modules producing data (like usb3-cameras or velodyne) may access the poses of the internal tree to add the pose as a metadata of the data product.

* Robot poses does not goes into meta-data, because they may be subject to changes after fusion: only the internal tree data is used as metadata because they are not subject to future change.

* If a client needs the robot base frame pose, it will look for it on PoM output poster/topic or get it through a request.

h3. Time management

* Time is going to be handled by a library that all clients may use to get current time.

* The interface should be completely independent, although internally this library may use ROS (probably enabled by means of compilation flags) or other mechanism to retrieve time (like gettimeofday or clock network synchronization)

h2. Whiteboard log

!White_board_meeting_POM_30_Mars_2018.jpg!