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)

 

*First, have a look to the [[Conventions]] page*

h2. Discussion

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

h3. PoM requirements

# *PoM has to provide the most recent pose of the robot body frame 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 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 body 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 body 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 body 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), expressed as poses*

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

  PoM may accept 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/ports, 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 transform 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, expressed as poses*

  _Why_: Because this is needed to update the robot 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), defined 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 robot body frame 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 update of memorised past poses 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) Reference 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:

* FrameID 1

* Timestamp 1

* FrameID 2

* Timestamp 2

* Transform From_1_to_2

* TransformCovariance

This way we can represent "normal poses" (same timestamp, different Frame IDs), "delta poses" (same frame ID, different timestamps), or even 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 properly 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 their pose with respect to the robot body frame (extracted from the internal robot tree of poses) to add this pose as a metadata of the data product.

* Robot body frame poses at the time of the data acquisition do not goes into the metadata of the data, because they may be subject to subsequent changes after fusion (contrary to the sensor pose with respect to the robot body frame, which will never be revised).

* If a client needs the robot body 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. List of requests to POM

h2. Whiteboard log

!White_board_meeting_POM_30_Mars_2018.jpg!