this repo has no description
cal(P) -> Pi
Signed-off-by: Gwenn Le Bihan <gwenn.lebihan7@gmail.com>
+54
-54
+38
-38
rapport/context.typ
+38
-38
rapport/context.typ
···
190
190
/ $S$: l'ensemble des états possibles de l'environnement
191
191
/ $rho_0: S -> [0, 1]$: la distribution de probabilité de l'état initial de l'environnement. Si l'on initialise l'environnement de manière uniformément aléatoire, $rho_0$ est une équiprobabilité#footnote[i.e. $card rho_0(S) = 1$]
192
192
/ $M: S times A -> S$: le moteur de simulation physique, qui applique l'action à un état de l'environnement et envoie le nouvel état de l'environnement
193
-
/ $cal(P): S -> A$: une politique
194
-
/ $cal(P)^*: S -> A$: la meilleure politique possible, celle que l'on cherche à approcher
193
+
/ $Pi: S -> A$: une politique
194
+
/ $Pi^*: S -> A$: la meilleure politique possible, celle que l'on cherche à approcher
195
195
/ $R: S -> RR^+$: sa fonction de récompense // d'une politique $p$
196
196
/ $Q_p: S times A -> [0, 1]$: sa distribution de probabilité, qu'on suppose Markovienne (elle ne dépend que de l'état dans lequel on est). $Q_p (s_t, a_t)$ est la probabilité que $p$ choisisse $a_t$ _quand on est dans l'état_ $s_t$ ($s_t$ est l'état *pré*-action, et non post-action)
197
-
/ $Q$ et $Q^*$: $Q_cal(P)$ et $Q_(cal(P)^*)$, pour alléger les notations
198
-
// $R$: $R_cal(P)$
197
+
/ $Q$ et $Q^*$: $Q_Pi$ et $Q_(Pi^*)$, pour alléger les notations
198
+
// $R$: $R_Pi$
199
199
200
200
On suppose $A$ et $S$ dénombrables#footnote[En pratique, $bb(R)$ est discrétisé dans les simulateurs numérique, donc cette hypothèse ne pose pas de problèmes à l'application de la théorie au domaine de la robotique].
201
201
···
210
210
211
211
212
212
213
-
$M$ et $cal(P)$ forment en fait tout se qui se passe pendant un pas de temps, c'est cette boucle que l'on répète pour soit entraîner l'agent (si l'on met $cal(P)$ à jour à chaque tour de boucle) ou l'utiliser:
213
+
$M$ et $Pi$ forment en fait tout se qui se passe pendant un pas de temps, c'est cette boucle que l'on répète pour soit entraîner l'agent (si l'on met $Pi$ à jour à chaque tour de boucle) ou l'utiliser:
214
214
215
215
#diagram(
216
216
node((0, 0), $s_t$),
217
217
edge(corner: right, label-pos: 2 / 8, label-side: left)[choix de l'action],
218
-
edge("->", corner: right, label-pos: 3 / 8, label-side: left)[$cal(P)$],
218
+
edge("->", corner: right, label-pos: 3 / 8, label-side: left)[$Pi$],
219
219
node((1, -1))[$a_t$],
220
220
edge("->", corner: right, label-pos: 5 / 8, label-side: left)[$M$],
221
221
edge(corner: right, label-pos: 6 / 8, label-side: left)[simulation],
···
223
223
edge((2, 0), (2, .75), (0, .75), (0, 0), "-->", label-side: left)[itération],
224
224
)
225
225
226
-
Quand on "déroule" $cal(P)$ en en partant d'un certain état initial $s_0$, on obtient une suite d'états et d'actions:
226
+
Quand on "déroule" $Pi$ en en partant d'un certain état initial $s_0$, on obtient une suite d'états et d'actions:
227
227
228
228
#diagram(
229
229
$
···
236
236
237
237
$
238
238
cases(
239
-
a_t & = cal(P)(s_t),
239
+
a_t & = Pi(s_t),
240
240
s_(t+1) & = M(s_t, a_t),
241
241
)
242
242
$
···
415
415
caption: [Boucle d'entraînement],
416
416
node((0, 0))[$s_t$],
417
417
edge("-"),
418
-
node(name: <policy>, (0, -1))[$cal(P)$],
418
+
node(name: <policy>, (0, -1))[$Pi$],
419
419
edge("->", corner: right),
420
420
node((1, -2))[$a_t$],
421
421
edge("->", corner: right)[$M$],
422
422
node(name: <final>, (2, 0))[$s_(t+1)$],
423
423
edge(<final>, (0, 0), "-->", label-side: left)[itération],
424
-
// edge("d,d,l,l,l,u,u,u", <policy>, "->", label-pos: 33%, label-side: left, align(center, [$Q_cal(P)(s_(t+1), argmax_(a in A) A_(cal(P), R)(s_(t+1), a)) <- A_(cal(P), R) (dots)$ \ Mise à jour]))
425
-
// edge("d,d,l,l,l,u,u,u", <policy>, "->", label-pos: 37%, label-side: left, align(center)[$argmax_(a in A) A_(cal(P), R)(s_(t+1), a)$ \ mise à jour de $cal(P)$])
424
+
// edge("d,d,l,l,l,u,u,u", <policy>, "->", label-pos: 33%, label-side: left, align(center, [$Q_Pi(s_(t+1), argmax_(a in A) A_(Pi, R)(s_(t+1), a)) <- A_(Pi, R) (dots)$ \ Mise à jour]))
425
+
// edge("d,d,l,l,l,u,u,u", <policy>, "->", label-pos: 37%, label-side: left, align(center)[$argmax_(a in A) A_(Pi, R)(s_(t+1), a)$ \ mise à jour de $Pi$])
426
426
edge("d,l,l,l,u,u", <policy>, "->", label-pos: 33%, label-side: left, align(
427
427
center,
428
428
)[
429
-
// mise à jour de $cal(P)$ \
430
-
$Q_cal(P)(s_(t+1), a_(t+1)^*) <- A_(cal(P), R)(s_(t+1), a_(t+1)^*)$
429
+
// mise à jour de $Pi$ \
430
+
$Q_Pi(s_(t+1), a_(t+1)^*) <- A_(Pi, R)(s_(t+1), a_(t+1)^*)$
431
431
]),
432
432
) <policy-update-loop>
433
433
434
434
Avec
435
435
436
436
$
437
-
a_(t+1)^* & := argmax_(a in A) A_(cal(P), R)(s_(t+1), a) \
437
+
a_(t+1)^* & := argmax_(a in A) A_(Pi, R)(s_(t+1), a) \
438
438
$
439
439
440
-
Mais, en pratique, des erreurs d'approximations peuvent rendre $A_(cal(P), R)(s_(t+1), a_(t+1)^*)$ négatif, ce qui empêche de s'en servir pour définir une valeur de $Q_(cal(P))$ @trpo
440
+
Mais, en pratique, des erreurs d'approximations peuvent rendre $A_(Pi, R)(s_(t+1), a_(t+1)^*)$ négatif, ce qui empêche de s'en servir pour définir une valeur de $Q_(Pi)$ @trpo
441
441
442
442
443
443
Le _surrogate advantage_ détermine la performance d'une politique par rapport à une autre
···
479
479
480
480
481
481
482
-
Pour évaluer cette distance, on regarde la plus grande des distances entre des paires de distributions de probabilité de politiques $Q_cal(P)$ et $Q_cal(P)'$ pour $s in S$ fixé @trpo
482
+
Pour évaluer cette distance, on regarde la plus grande des distances entre des paires de distributions de probabilité de politiques $Q_Pi$ et $Q_Pi'$ pour $s in S$ fixé @trpo
483
483
484
484
$
485
-
max_(s in S) D_"KL" (Q_cal(P)' (s, dot) || Q_cal(P) (s, dot)) < delta
485
+
max_(s in S) D_"KL" (Q_Pi' (s, dot) || Q_Pi (s, dot)) < delta
486
486
$
487
487
488
488
···
519
519
520
520
==== Région de confiance
521
521
522
-
Cette contrainte définit un ensemble réduit de $cal(P)'$ acceptables comme nouvelle politique, aussi appelé une _trust region_ (région de confiance), d'où la méthode d'optimisation tire son nom @trpo.
522
+
Cette contrainte définit un ensemble réduit de $Pi'$ acceptables comme nouvelle politique, aussi appelé une _trust region_ (région de confiance), d'où la méthode d'optimisation tire son nom @trpo.
523
523
524
524
#let ddot = [ #sym.dot #h(-1em / 16) #sym.dot ]
525
525
···
540
540
541
541
542
542
$
543
-
argmax_(cal(P)') & exp_((s, a) in cal(S)) L(s, a, cal(P), cal(P'), R) \
543
+
argmax_(Pi') & exp_((s, a) in cal(S)) L(s, a, Pi, Pi', R) \
544
544
"s.c." & top
545
545
$
546
546
···
549
549
_PPO-Penalty_ soustrait une divergence K-L pondérée à l'avantage:
550
550
551
551
$
552
-
L(s, a, cal(P), cal(P'), R) = (Q_cal(P) (s, a)) / (Q_cal(P') (s, a)) A_(cal(P), R) (s, a) - beta D_"KL" (cal(P) || cal(P'))
552
+
L(s, a, Pi, Pi', R) = (Q_Pi (s, a)) / (Q_Pi' (s, a)) A_(Pi, R) (s, a) - beta D_"KL" (Pi || Pi')
553
553
$
554
554
555
555
Avec $beta$ ajusté automatiquement pour être dans la même échelle que l'autre terme de la soustraction.
···
560
560
561
561
562
562
$
563
-
L(s, a, cal(P), cal(P'), R) = min(
564
-
& (Q_cal(P)' (s, a)) / (Q_cal(P) (s, a)) A_(cal(P)', R)(s, a), quad \
563
+
L(s, a, Pi, Pi', R) = min(
564
+
& (Q_Pi' (s, a)) / (Q_Pi (s, a)) A_(Pi', R)(s, a), quad \
565
565
&op("clip")(
566
-
(Q_cal(P)' (s, a)) / (Q_cal(P) (s, a)),
566
+
(Q_Pi' (s, a)) / (Q_Pi (s, a)),
567
567
1 - epsilon,
568
568
1 + epsilon
569
-
) A_(cal(P)', R)(s, a)
569
+
) A_(Pi', R)(s, a)
570
570
)
571
571
$
572
572
···
580
580
)
581
581
$
582
582
583
-
La complexité de l'expression, et la présence d'un $min$ au lieu de simplement un $op("clip")$ est dûe au fait que l'avantage $A_(cal(P)', R) (s, a)$ peut être négatif. L'expression se simplifie en séparant les cas (cf @proof-ppo-clip-simplify)
583
+
La complexité de l'expression, et la présence d'un $min$ au lieu de simplement un $op("clip")$ est dûe au fait que l'avantage $A_(Pi', R) (s, a)$ peut être négatif. L'expression se simplifie en séparant les cas (cf @proof-ppo-clip-simplify)
584
584
585
585
#let named_point = (
586
586
x,
···
606
606
607
607
#dontbreak[
608
608
609
-
/ Si l'avantage est positif: $a$ est un meilleur choix que $cal(P)(s)$.
609
+
/ Si l'avantage est positif: $a$ est un meilleur choix que $Pi(s)$.
610
610
611
611
#equation_and_diagram(
612
612
$
613
-
L(s, a, cal(P), cal(P)', R) = min(
614
-
(Q_cal(P)' (s, a)) / (Q_cal(P) (s, a)),
613
+
L(s, a, Pi, Pi', R) = min(
614
+
(Q_Pi' (s, a)) / (Q_Pi (s, a)),
615
615
quad 1 + epsilon
616
-
) A_(cal(P)', R)(s, a)
616
+
) A_(Pi', R)(s, a)
617
617
$,
618
618
diagram(
619
619
spacing: (2.7em, 2em),
620
-
node((-1, 0))[$cal(P)'$],
620
+
node((-1, 0))[$Pi'$],
621
621
edge((-1, 0), "->", (3, 0), stroke: luma(150)),
622
622
edge((-1, 0), "-|", (1, 0), extrude: (1, -1, 0)),
623
623
named_point(1, 0, shape: "|")[$1+epsilon$],
624
-
named_point(0, 0)[$cal(P)$],
624
+
named_point(0, 0)[$Pi$],
625
625
named_point(1.5, 0, color: red, side: left)[$times$],
626
626
named_point(0.5, 0, color: olive, side: left)[$checkmark$],
627
627
),
628
628
)
629
629
630
-
/ Si l'avantage est négatif: choisir $a$ est pire que garder $cal(P)(s)$.
630
+
/ Si l'avantage est négatif: choisir $a$ est pire que garder $Pi(s)$.
631
631
632
632
#equation_and_diagram(
633
633
$
634
-
L(s, a, cal(P), cal(P)', R) = max(
634
+
L(s, a, Pi, Pi', R) = max(
635
635
1 - epsilon, quad
636
-
(Q_cal(P)' (s, a)) / (Q_cal(P) (s, a))
637
-
) A_(cal(P)', R)(s, a)
636
+
(Q_Pi' (s, a)) / (Q_Pi (s, a))
637
+
) A_(Pi', R)(s, a)
638
638
$,
639
639
diagram(
640
640
spacing: (2.7em, 2em),
641
-
node((3, 0))[$cal(P)'$],
641
+
node((3, 0))[$Pi'$],
642
642
edge((-1, 0), "<-", (3, 0), stroke: luma(150)),
643
643
edge((1, 0), "|-", (3, 0), extrude: (1, -1, 0)),
644
644
named_point(1, 0, shape: "|")[$1-epsilon$],
645
-
named_point(2, 0)[$cal(P)$],
645
+
named_point(2, 0)[$Pi$],
646
646
named_point(0, 0, color: red, side: left)[$times$],
647
647
named_point(1.5, 0, color: olive, side: left)[$checkmark$],
648
648
),
···
655
655
// 1. Mise à jour de la politique:
656
656
//
657
657
// $
658
-
// cal(P') = argmax_p 1/T sum_(t=1)^T L(s, a, cal(P), p, R)
658
+
// Pi' = argmax_p 1/T sum_(t=1)^T L(s, a, Pi, p, R)
659
659
// $
660
660
661
661
+9
-9
rapport/gz-unitree.typ
+9
-9
rapport/gz-unitree.typ
···
152
152
2. L'interaction avec les canaux DDS du SDK d'Unitree
153
153
3. Les données et méthodes internes au plugin
154
154
155
-
En plus de cela, il y a bien évidemment la politique de contrôle $cal(P)$, qui interagit via les canaux DDS avec le robot (qu'il soit réel, ou simulé)
155
+
En plus de cela, il y a bien évidemment la politique de contrôle $Pi$, qui interagit via les canaux DDS avec le robot (qu'il soit réel, ou simulé)
156
156
157
157
#let legend = (
158
158
..descriptions,
···
243
243
node(name: <cmdbuf>, (2, 3), subtitled("Commands buffer", `cmdbuf`))
244
244
group((<lowstate>, <lowcmd>, <statebuf>, <cmdbuf>, <gzclock>, <gzimu>))[Plugin internals]
245
245
246
-
node(name: <policy>, (0, -1), $cal(P)$)
246
+
node(name: <policy>, (0, -1), $Pi$)
247
247
248
248
for e in edges.pos() {
249
249
e
···
388
388
389
389
=== Réception des commandes <receive-lowcmd>
390
390
391
-
Lorsqu'un message, publié par $cal(P)$ (1A) et contenant des ordres pour les moteurs, arrive sur `rt/lowcmd`, `::CmdHandler` est appelé (2, 3), et modifie un _buffer_ (4) contenant la dernière commande reçue.
391
+
Lorsqu'un message, publié par $Pi$ (1A) et contenant des ordres pour les moteurs, arrive sur `rt/lowcmd`, `::CmdHandler` est appelé (2, 3), et modifie un _buffer_ (4) contenant la dernière commande reçue.
392
392
393
393
394
394
Ensuite, Gazebo démarre un nouveau pas de simulation. Avant de faire ce pas, il appelle la méthode `::PreUpdate` sur notre plugin, qui vient chercher la commande stockée dans le _buffer_ (1B), et applique cette commande sur le modèle du robot, animé par le simulateur.
···
579
579
580
580
Avant de démarrer un nouveau pas de simulation, la méthode `::PreUpdate` vient mettre à jour l'état du robot simulé en modifiant le _State buffer_ interne au plugin (1A).
581
581
582
-
Le `LowStateWriter` vient lire le _State buffer_ (1B) pour publier l'état sur le canal DDS (2, 3) qui est ensuite lu par $cal(P)$ (4), qui (on le suppose) possède une subscription sur `rt/lowstate`
582
+
Le `LowStateWriter` vient lire le _State buffer_ (1B) pour publier l'état sur le canal DDS (2, 3) qui est ensuite lu par $Pi$ (4), qui (on le suppose) possède une subscription sur `rt/lowstate`
583
583
584
584
585
585
#let transparent = luma(0).opacify(0%)
···
613
613
614
614
- La boucle de simulation de Gazebo (fréquence d'appel de `::PreUpdate`),
615
615
- La boucle du `ChannelPublisher` (fréquence d'appel de `::LowStateWriter`), et
616
-
- La boucle de réception de $cal(P)$ (à quelle fréquence $cal(P)$ est-elle capable de reçevoir des messages)
616
+
- La boucle de réception de $Pi$ (à quelle fréquence $Pi$ est-elle capable de reçevoir des messages)
617
617
618
618
619
619
Similairement à la réception de commandes:
620
620
621
621
/ Si `::PreUpdate` est plus fréquente: On perdra des états intermédiaires, la résolution temporelle de l'évolution de l'état du robot disponible pour (ou acceptable par#footnote[
622
-
En fonction de si `::LowStateWriter` est plus fréquente que $cal(P)$ (dans ce cas là, c'est ce qui est acceptable par $cal(P)$ qui est limitant) ou inversement (dans ce cas, c'est ce que la boucle du publisher met à disposition de $cal(P)$ qui est limitant)
623
-
]) $cal(P)$ sera moins grande
624
-
/ Si `::PreUpdate` est moins fréquente: $cal(P)$ reçevra plusieurs fois le même état, ce qui sera représentatif du fait que la simulation n'a pas encore avancé.
622
+
En fonction de si `::LowStateWriter` est plus fréquente que $Pi$ (dans ce cas là, c'est ce qui est acceptable par $Pi$ qui est limitant) ou inversement (dans ce cas, c'est ce que la boucle du publisher met à disposition de $Pi$ qui est limitant)
623
+
]) $Pi$ sera moins grande
624
+
/ Si `::PreUpdate` est moins fréquente: $Pi$ reçevra plusieurs fois le même état, ce qui sera représentatif du fait que la simulation n'a pas encore avancé.
625
625
626
626
627
627
== Désynchronisations
···
632
632
633
633
/ Bleu: Simulation, qui doit englober l'entièreté d'un cycle
634
634
/ Rouge: `ChannelPublisher`
635
-
/ Rose: Politique $cal(P)$
635
+
/ Rose: Politique $Pi$
636
636
/ Vert: Mise à jour de l'IMU
637
637
/ Orange: Mise à jour du tick de simulation
638
638
rapport/main.pdf
rapport/main.pdf
This is a binary file and will not be displayed.
+4
-4
rapport/proofs.typ
+4
-4
rapport/proofs.typ
···
105
105
&= eta(p, r) quad qed
106
106
$
107
107
108
-
== Simplification de l'expression de $L(s, a, cal(P), cal(P)', R)$ dans PPO-Clip <proof-ppo-clip-simplify>
108
+
== Simplification de l'expression de $L(s, a, Pi, Pi', R)$ dans PPO-Clip <proof-ppo-clip-simplify>
109
109
110
110
#let clip = $op("clip")$
111
111
112
-
Soit $(s, a) in S times A$, et $cal(P)'$ une politique. Posons $alpha &:= A_(cal(P)', R) (s, a)$, $q slash q' &:= Q_cal(P) (s, a) slash Q_cal(P)' (s, a)$ .
112
+
Soit $(s, a) in S times A$, et $Pi'$ une politique. Posons $alpha &:= A_(Pi', R) (s, a)$, $q slash q' &:= Q_Pi (s, a) slash Q_Pi' (s, a)$ .
113
113
114
114
#let why = explanation => $\ & quad quad #[car #explanation]$
115
115
···
128
128
[
129
129
130
130
$
131
-
&L(s, a, cal(P), cal(P'), R) \
131
+
&L(s, a, Pi, Pi', R) \
132
132
&= min(q/q' alpha, quad clip(q/q', thick 1-epsilon, thick 1+epsilon) alpha) \
133
133
&= min(q/q', quad clip(q/q', thick 1-epsilon, thick 1+epsilon)) alpha why(alpha > 0) \
134
134
$
···
136
136
[
137
137
138
138
$
139
-
&L(s, a, cal(P), cal(P'), R) \
139
+
&L(s, a, Pi, Pi', R) \
140
140
&= min(q/q' alpha, quad clip(q/q', thick 1-epsilon, thick 1+epsilon) alpha) \
141
141
&= max(q/q', quad clip(q/q', thick 1-epsilon, thick 1+epsilon)) alpha why(alpha < 0) \
142
142
$
+3
-3
rapport/sdk2-study.typ
+3
-3
rapport/sdk2-study.typ
···
177
177
Le fonctionnement d'un bridge est au final assez similaire, quelque soit le simulateur pour lequel on l'écrit: il s'agit d'envoyer l'état du robot au simulateur, et de réagir quand le simulateur envoie des ordres de commandes.
178
178
179
179
#figure(caption: "Fonctionnement usuel du SDK", diagram({
180
-
node((0, 0), $cal(P)$)
180
+
node((0, 0), $Pi$)
181
181
node((1, 0), "SDK")
182
182
node((2, 0), "Robot")
183
183
···
195
195
196
196
197
197
#figure(caption: [Fonctionnement via _unitree\_mujoco_ du SDK], diagram({
198
-
node((0, 0), $cal(P)$)
198
+
node((0, 0), $Pi$)
199
199
node((1, 0), "SDK")
200
200
node((2, 0))[`unitree_mujoco`]
201
201
node((3, 0), "Mujoco")
···
218
218
219
219
220
220
#figure(caption: [Fonctionnement via _gz-unitree_ du SDK], diagram({
221
-
node((0, 0), $cal(P)$)
221
+
node((0, 0), $Pi$)
222
222
node((1, 0), "SDK")
223
223
node((2, 0))[`gz-unitree`]
224
224
node((3, 0), text(fill: blue)[Gazebo])