this repo has no description
Continue rapport
+14
-6
+14
-6
rapport/sdk2-study.typ
+14
-6
rapport/sdk2-study.typ
···
231
231
edge((2, 1), (3, 1), "|-|", stroke: blue + 1.25pt, label-side: right, text(fill: blue)[*API de Gazebo*])
232
232
}))
233
233
234
-
Le bridge de Mujoco fonctionne en interceptant les messages sur les canaux `rt/lowcmd` et `rt/lowstate`, qui correspondent respectivement aux commandes envoyées au robot et à l'état (angles des joints, moteurs, valeurs des capteurs, etc) renvoyé par le robot. Le `low` indique que ce sont des messages bas-niveau: par exemple, `rt/lowcmd` correspond directement à des ordres de tension pour les moteurs, et non pas à des messages plus avancés du type "avancer de $x$ mètres" #todo[ces messages plus haut-niveau = sport mode non? dire quand ils servent]
234
+
Le bridge de Mujoco fonctionne en interceptant les messages sur le canal `rt/lowcmd` et en en envoyant dans le canal `rt/lowstate`, qui correspondent respectivement aux commandes envoyées au robot et à l'état (angles des joints, moteurs, valeurs des capteurs, etc) renvoyé par le robot.
235
+
236
+
Le `low` indique que ce sont des messages bas-niveau: par exemple, `rt/lowcmd` correspond directement à des ordres de tension pour les moteurs, et non pas à des messages plus avancés du type "avancer de $x$ mètres" #todo[ces messages plus haut-niveau = sport mode non? dire quand ils servent]
235
237
236
238
Les ordres dans `rt/lowcmd` sont ensuite traduits en appels de fonctions de Mujoco pour mettre à jour l'état du robot simulé, et de messages `rt/lowstate` sont créés à partir des données fournies par Mujoco
237
239
238
-
#figure(caption: [Cycle de vie de la simulation avec le bridge], diagram({
240
+
Étant donné le modèle _pub/sub_ de DDS, on parle de _pub(lication)_ de message, et de _sub(scription)_#footnote[abonnement] aux messages d'un canal (pour les recevoir)
241
+
242
+
#figure(caption: [Cycle de vie de la simulation avec le bridge pour Mujoco], diagram({
239
243
node(name: <sdk>, (0, 0))[SDK]
240
244
node(enclose: ((1, 1), (-1, 1)), stroke: blue, inset: 10pt, snap: false, text(fill: blue)[Canaux \ DDS])
241
245
node(name: <lowcmd>, (1, 1))[`rt/lowcmd`]
···
245
249
246
250
247
251
edge(<sdk>, <lowcmd>, "->", bend: 30deg)[pub]
248
-
edge(<lowcmd>, (1, 2), "..>", bend: 20deg)[sub]
249
-
edge((1, 2), <mujoco>, "->", bend: 20deg, todo[])
252
+
edge(<lowcmd>, (1, 2), "..>", bend: 20deg)[via sub]
253
+
edge((1, 2), <mujoco>, "->", bend: 20deg, `data->ctrl[i] = ...`)
250
254
251
-
edge(<sdk>, <lowstate>, "<..", bend: -30deg)[sub]
255
+
edge(<sdk>, <lowstate>, "<..", bend: -30deg)[via sub]
252
256
edge(<lowstate>, (-1, 2), "<-", bend: -20deg)[pub]
253
-
edge((-1, 2), <mujoco>, "<-", bend: -20deg, todo[])
257
+
edge((-1, 2), <mujoco>, "<-", bend: -20deg, `... = data->sensordata[i]`)
258
+
259
+
edge(<mujoco>, <mujoco>, "->", bend: 130deg, loop-angle: -90deg, `mj_step(model, data)`)
254
260
}))
261
+
262
+
Le but est donc de reproduire un cycle de vie équivalent, mais en remplaçant la partie spécifique à Mujoco par une partie adaptée à Gazebo.