0315 » History » Version 4
Pierre Narvor, 2018-03-16 12:38
1 | 1 | Pierre Narvor | h1. 03/14-15 : PoM/Prism Discussion (details) |
---|---|---|---|
2 | |||
3 | *Participants :* |
||
4 | Simon, Ellon, Quentin, Pierre |
||
5 | |||
6 | 2 | Pierre Narvor | *Goal of the meeting :* Discuss the PoM/Prism Details. |
7 | 1 | Pierre Narvor | |
8 | 3 | Pierre Narvor | *Notes :* |
9 | * After the first meeting, Prism design appeared more complicated than previously thought. Quentin and Pierre met afterward to think about a potential solution. |
||
10 | * Pose and transform are used interchangeably in the following and are always accompanied with a parent frame id, a child frame id and an uncertainty matrix. |
||
11 | * In the following, the word "Produce" mean a node create data but not necessarily "Publish" it for other nodes (Example : sensors node produce raw data but only publish stamped data). |
||
12 | 1 | Pierre Narvor | |
13 | |
||
14 | |
||
15 | |||
16 | 3 | Pierre Narvor | h2. 1. Summary of "starting point" |
17 | 1 | Pierre Narvor | |
18 | |
||
19 | |||
20 | 3 | Pierre Narvor | *1. "Mandatory" nodes producing raw data* |
21 | 1 | Pierre Narvor | |
22 | 3 | Pierre Narvor | * Joint nodes : produce and publish poses between joint base and joint head (a "Joint node" here can represent a succession of several hardware joints, like an arm with several hinges. But a joint node has to publish only a single pose from the base to the head. Make several joint nodes if every hinge position has to be passed to Prism. */!\* Even a joint node representing a simple hinge has to publish a whole pose : [translation vector, rotation quaternion, uncertainty matrix, parent and child frame id ]). |
23 | * Sensor nodes : produce raw sensor data (point clouds, etc...) . |
||
24 | 1 | Pierre Narvor | |
25 | |
||
26 | |||
27 | 3 | Pierre Narvor | *2. "Mandatory" nodes receiving processed data* |
28 | 1 | Pierre Narvor | |
29 | 2 | Pierre Narvor | * Localization DFPCs, receives stamped data : raw sensor data stamped with a time stamp and a pose(RobotBase->Sensor) |
30 | 1 | Pierre Narvor | * MightlyLocalizer (part of POM) receives time stamp : time stamp at sensor data acquisition date. |
31 | |||
32 | |
||
33 | |||
34 | *3. Constraints* |
||
35 | |||
36 | 4 | Pierre Narvor | * Centralized time : Every time stamp has to come from a single node : POM (Both Prism and MightyLocalizer ? Or only one of the two ?). |
37 | 1 | Pierre Narvor | * Publish/Subscribe only : No direct services between nodes allowed. |
38 | 3 | Pierre Narvor | * Sensors only know their frame id and are not managing transform propagation between sensor frame and robot frame. These are managed elsewhere (Prism). |
39 | 1 | Pierre Narvor | |
40 | 3 | Pierre Narvor | |
41 | |
||
42 | 1 | Pierre Narvor | |
43 | 3 | Pierre Narvor | |
44 | |||
45 | h2. 2. Prism design, second draw (see last meeting for first draw) |
||
46 | |||
47 | |
||
48 | |||
49 | *Prism goal :* |
||
50 | |||
51 | * Managing the internal transform tree of the robot (only for sensors). Receives information about sensor mount joint positions and update the internal tree. Publish poses(robotBase->sensors) |
||
52 | * Publish time stamp at sensor data acquisition (for use in sensor nodes and POM). |
||
53 | |||
54 | These two information have to be used by sensor nodes for them to publish time and pose stamped data. The problem is if it is Prism which has to publish time stamp at sensor data acquisition (as decided in the last meeting), the sensor node has to notify Prism when raw data has been produced. This will be problematic with only publish/subscribe communication. |
||
55 | |
||
56 | After discussion (Quentin, Pierre), it appeared easier to let the sensor node publish a time stamp for POM instead of prism. (in addition to publish time stamped data for localization nodes). Prism will publish time stamped poses at (relatively) high frequency for sensor nodes regardless of data being produces by sensor nodes or not. This way a sensor node can read at data acquisition the last time stamped sensor pose published by Prism and proceed to publish stamped data, and a time stamp related only to a data acquisition. |
||
57 | |||
58 | !Prism2.png! |
||
59 | |||
60 | h2. 3. Prism implementation details |
||
61 | |||
62 | |
||
63 | |||
64 | h3. ASN.1 messages |
||
65 | |||
66 | |
||
67 | *Joint to Prism : ASN.1 Transform* |
||
68 | <pre><code class="Cpp"> |
||
69 | ASN.1 Transform |
||
70 | { |
||
71 | Vec3d position |
||
72 | Quaterniond orientation |
||
73 | Matrix6d cov |
||
74 | T-String parentFrame |
||
75 | T-String childFrame |
||
76 | }; |
||
77 | </code></pre> |
||
78 | |||
79 | |
||
80 | *Prism to sensors : ASN.1 Pom2Sensor :* |
||
81 | <pre><code class="Cpp"> |
||
82 | ASN.1 Pom2Sensor |
||
83 | { |
||
84 | Time ts |
||
85 | SEQUENCE(SIZE (1...NbSensorMax)) OF Transform |
||
86 | }; |
||
87 | </code></pre> |
||
88 | Note : Prism publish an array of sensor poses. It is up to the sensor to choose the correct sensor pose (the sensor now its own frameId) |
||
89 | |||
90 | |
||
91 | *Sensor to Pom: ASN.1 Sensor2Pom :* |
||
92 | <pre><code class="Cpp"> |
||
93 | ASN.1 Pom2Sensor |
||
94 | { |
||
95 | Time ts |
||
96 | T-String childFrame (= sensorFrame) |
||
97 | }; |
||
98 | </code></pre> |
||
99 | |||
100 | |
||
101 | |||
102 | h3. Prism implementation |
||
103 | |||
104 | <pre><code class="Cpp"> |
||
105 | class Prism |
||
106 | { |
||
107 | attributes: |
||
108 | |||
109 | EnvireGraph _internalRobotGraph; |
||
110 | BitStream(ASN1_Transform)* JointStateBuffer; //(circular buffer of ASN1 bitstreams to handle both high and low frequency joint pose publishing) |
||
111 | ASN1_Transform(*) JointState; |
||
112 | ASN1_Pom2Sensor sensorPoses*; |
||
113 | |||
114 | members: |
||
115 | |||
116 | updateGraph(jointState) |
||
117 | decode_message(ASN1 bitstream) //decode jointState messages |
||
118 | encode_messages // encode array of sensor poses |
||
119 | }; |
||
120 | </code></pre> |