0315 » History » Revision 2
Revision 1 (Pierre Narvor, 2018-03-16 09:56) → Revision 2/5 (Pierre Narvor, 2018-03-16 10:40)
h1. 03/14-15 : PoM/Prism Discussion (details) *Participants :* Simon, Ellon, Quentin, Pierre *Goal of the meeting :* Discuss the PoM/Prism Details. architecture (previously InSitu). Prism is the sub-task of PoM which handle the internal transform tree of a robot (RobotBaseFrame to SensorFrame(s)). *Note :* After PoM is divided in two parts: Prism which handles the first meeting, Prism design appeared more complicated than previously thought. Quentin pose of sensors relative to the robot and Pierre met afterward (name undefined, default = MightyLocalizer) MightyLocalizer which handles the pose of the robot frame relative to think the world frames (absolute, site, local). The meeting is only about a potential solution. Prism. Pose h2. 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 are used interchangeably in tree. No memory of the following 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 always accompanied 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 parent world frame id, of the sensor that acquired data (or of the RobotBaseFrame at the time of data acquisition) may be revised (typically, by a child frame id and an uncertainty matrix. 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. h2. 1. Summary of the objectives and constraints (without design details) Details *1. Nodes producing raw data* h3. Loading and maintaining internal tree * Joints *Internal Tree :* all SensorFrames connected to the RobotBaseFrame through one or several edges. Two types of edges : produce poses between fixed or moving. !Prism.png! * *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 base (i.e. platine module) to initialize and communicate the right value. What we do in the URDF is say "there is a joint head. there" * Sensors : produce *Maintaining the tree :* Prism receives poses from all the moving sensor data (point clouds, etc...) . mounts. Movable edges in the internal tree are updated right away (no memory). To define: communication between joints and Prism (identification of joints etc...). *2. Nodes receiving processed data* h3. Sensor pose service * Localization DFPCs, receives stamped data : raw Acquired sensor data stamped has to be associated with a pose of the sensor and a time stamp stamp. The SensorFrame to RobotBaseFrame transform (furnished by Prism) is measured at the time of the acquisition and a pose(RobotBase->Sensor) 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). * MightlyLocalizer (part *Content of POM) receives 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 :* # Data acquisition by sensor # Sensor node asks Prism for a time stamp at and a pose # Sensor node publish a complete data struct Two options can be foreseen: # When a sensor acquires a data, it notifies Prism # Prism gets the associated transform # 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 acquisition date. (upon a request by the sensor node to Prism) *3. Constraints* h3. Send time stamp to mighty-localizer for saving * Centralized The time : POM is stamp at time of acquisition must be saved by MightyLocalizer for the master case where a localization DFPC needs the RobotBaseFrame to WorldFrame pose at time of time. Every time stamp has to come from POM. data acquisition. !WorkFlow.png! * Publish/Subscribe only : No direct services between nodes allowed. * Sensors only know their frame id and are not managing transform propagation between sensor frame and robot frame. These are managed elsewhere (prism). !Prism_meeting_board.jpg!