03/09 : PoM/Prism Discussion¶

Participants :
Simon, Ellon, Quentin, Pierre

Goal of the meeting : Discuss the PoM/Prism architecture (previously InSitu). Prism is the sub-task of PoM which handle the internal transform tree of a robot (RobotBaseFrame to SensorFrame(s)).

Note : PoM is divided in two parts: Prism which handles the pose of sensors relative to the robot and (name undefined, default = MightyLocalizer) MightyLocalizer which handles the pose of the robot frame relative to the world frames (absolute, site, local). The meeting is only about Prism.

 
 

Features of Prism¶

• Load and maintain the RobotBaseFrame to SensorFrame(s) tree of the robot up to date: URDF configuration file for initialization. Is a client of moving sensor mounts (arms, orientable devices such as a Pan&Tilt Unit...) to update the internal transform tree. No memory of the past trees has to be maintained. Handles transform uncertainties.

• Sensor pose service: Any sensor acquiring exteroceptive data (vision, stereovision, Lidar) must ask Prism for a time stamp and a sensor pose (= current transform RobotBaseFrame to SensorFrame + uncertainty). The pose and the time are stored by the sensor node as metadata of the sensor data (this pose will be of use only with this data, hence no memory is needed in Prism).

• Send time stamp to mighty-localizer for saving: In the future, some poses in a world frame of the sensor that acquired data (or of the RobotBaseFrame at the time of data acquisition) may be revised (typically, by a SLAM node). For the MightyLocaliser to manage theses poses (to update them, or to deliver it to a node that need them - typically the DEM node), they must be memorised: by sending the time stamps associated to data acquisitions, Prism notifies the MightyLocaliser that the poses in the world frames must be memorised.

 

Details¶

 

Loading and maintaining internal tree¶

• Internal Tree : all SensorFrames connected to the RobotBaseFrame through one or several edges. Two types of edges : fixed or moving.

• Initialization: Internal tree building form URDF file. Do we need default values for moving edges to define? Quentin says: I don't think so. It will be the role of the module in charge of the joint (i.e. platine module) to initialize and communicate the right value. What we do in the URDF is say "there is a joint there"

• Maintaining the tree : Prism receives poses from all the moving sensor mounts. Movable edges in the internal tree are updated right away (no memory). To define: communication between joints and Prism (identification of joints etc...).

 
 

Sensor pose service¶

Acquired sensor data has to be associated with a pose of the sensor and a time stamp.

The SensorFrame to RobotBaseFrame transform (furnished by Prism) is measured at the time of the acquisition and will NOT be modified later. Hence, no memory is needed in Prism and the SensorFrame to RobotFrame transform is recorded alongside the data outside of Prism. (the RobotBaseFrame to WorldFrame recorded at the time of acquisition may however be modified later by MightyLocalizer).

• Content of a data structure : The data is published in a structure alongside the time stamp and pose at the acquisition, and two FrameId (SensorFrameId and RobotBaseFrameId).

• Workflow :

1. Data acquisition by sensor
2. Sensor node asks Prism for a time stamp and a pose
3. Sensor node publish a complete data struct

Two options can be foreseen:

1. When a sensor acquires a data, it notifies Prism
2. Prism gets the associated transform
3. Prism delivers the sensor to RobotBaseFrame to the sensor (and its time stamp)

An alternate way is to have the moving sensor mounts permanently broadcast their transforms, and Prism systematically computes the associated tree branch. The corresponding transform is provided to the sensor when it acquires data (upon a request by the sensor node to Prism)

 
 

Send time stamp to mighty-localizer for saving¶

The time stamp at time of acquisition must be saved by MightyLocalizer for the case where a localization DFPC needs the RobotBaseFrame to WorldFrame pose at time of data acquisition.