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)

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.

PoM requirements¶

1. PoM has to provide most recent robot pose
   Why: Some clients need to know this pose in a high frequency (control, trajectory, velodyne, etc..)
   This pose is the product of the input poses from the localization process. It is done synchronous (i.e. periodic) on a topic/poster. The robot pose is relative to the world frame
    
2. PoM has to provide the sensor pose in robot frame for each living sensor, configured at start up.
   Why: Because clients that produce data may need to know these poses to attach to the data
   The start up configuration may be done through requests (but maybe also by a configuration file?). This way PoM will only output transformation from its internal tree to some sensors that needs it, instead of publishing the complete tree each time. The output is synchronous, as it is with the most recent pose. This output should be synchronized with the most recent robot pose (i.e. has the same timestamp, so clients may associate them).
    
3. PoM has to gather all localization information, as pose or delta-poses (increments)
   Why: PoM need this information to fuse them later
   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 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.
    
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 one.
   This request will mostly be used by DEM on this sprint.
    
5. PoM has to gather information about internal joints of the robots, as poses only.
   Why: Because this is needed to update internal tree of poses.
   The tree is loaded from a URDF file. The information about non-static joints/branches enters PoM through topics/ports, probably the same way it's done with localization information.
    
6. PoM has to perform the fusion of gathered localization information
   Why: This is needed to provide the best pose.
    
   NOTE: This won't be implemented on sprint 4!
    
7. PoM has to provide two services to let clients tell him which poses to memorize 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 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 will remove poses that the system won't need anymore.
    
   NOTE: Only the internal buffer will be implemented on sprint 4.

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), delta-poses (same frame ID) or poses between different frames at different times, e.g. "Pose of 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.

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: only the internal tree data is used as metadata because they are not subject to future change.

• If a client needs the robot 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)

Whiteboard log¶