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

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.

PoM requirements¶

1. 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.
    
2. 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).
    
3. 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.
    
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.
    
5. 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.
    
6. 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
    
7. 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!
    
8. 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.

genericTransform type¶

We decided to use a generic pose type defined as follows:

• 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.

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.

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)

POM interfaces¶

Data flow¶

Besides control parameters, POM imports and exports only genericTransforms.

• Imports
  • POM imports the genericTransform produced by the variable sensor mounts nodes (in which the timestamps are equal): this is to feed the internal tree of poses. These transforms are systematically read at every period of POM. Note: this does not involve any particular way of proceeding for the mounts: the can export these transforms at any rate.
  • POM imports the genericTransform produced by the localisation DFPCs. Most likely, these transforms will be read upon a request to POM. Note: we may define the associated topic (and request parameters) so that POM imports a list of genericTransforms instead of a single one? (this will the case when PG-SLAM closes a loop for instance)

• Exports
  • POM periodically exports the GenericTransform RBFPose_2_ReferenceFrame
  • POM periodically exports the GenericTransform Sensor_2_RBF for each declared sensor
  • Upon request, POM exports a GenericTransform RBFPose_2_ReferenceFrame at a given timestamp t, ReferenceFrame and t being parameters of the request. Note: we may define the associated topic (and request parameters) so that POM exports a list of genericTransforms? (this will be the case when one want to build a Total Rover Map for instance)

Control flow¶

The various requests associated to POM are:

• Configuration requests. Most often called once at the POM initialisation, they can nevertheless be called during the POM life.
  • activateSensor (sensorID): this implies that the sensorId frame will be periodically exported. The deActivateSensor configuration request is also defined.
  • addVariableMount (mountID): this implies that the genericTransform produced the node associated to the defined mount will be regularly read. The removeVariableMount configuration request can also be defined.
  • setReferenceFrame: to define the frame in which are expressed the exported RBF poses
  • Start: to trigger the start of POM (which must be made after a series of configuration requests)

Note: in the URDF file that describes the various robot frames, one should define the various sensorID and mountIDs, no?

• Computation requests. They are regularly called during the life of POM.
  • fuseEstimate (localisationProcessID): this causes POM to read a genericTransform produced by the given localisation process, and to fuse it within the history of poses. Note this request could take as inputs a series of genericPoses (as produced by PG-SLAM for instance)
  • getRBFPose (timestamp, referenceFrame and associated timestampRef): tells POM to export the genericTransform that represents at time "timestamp" the RBF pose expressed in the referenceFrame at the time "timestampRef". Every time this request is emitted to POM (e.g. by the DEM and PG-SLAM DFPCs), POM should be warned that the produced pose may be later re-asked, and that it should be memorised. This could be made automatically (solution preferred by Simon), by incrementing a reference counter on the asked pose, or upon a dedicated request?
  • clearReference (timestamp): this tells POM that a client who asked a RBF pose at time "timestamp" will not need it anymore. This would then decrement the reference counter associated to this pose in the memory of POM.
  • garbageCollect: to clean the memory of POM. Note that a simple management of the reference counters should allow to live without such a request.

Whiteboard log¶