this repo has no description
Continue rapport
+23
-19
+8
bib.yaml
+8
bib.yaml
+7
-12
rapport/context.typ
+7
-12
rapport/context.typ
···
1
-
#import "utils.typ": comment, dontbreak, refneeded, todo
1
+
#import "utils.typ": dontbreak
2
2
#import "@preview/fletcher:0.5.8": edge, node
3
3
#import "@preview/fletcher:0.5.8"
4
4
#import "@preview/diagraph:0.3.6"
···
137
137
138
138
L'expression comporte deux hyperparamètres, à valeurs dans $]0, 1[$:
139
139
140
-
/ Learning rate $alpha$: contrôle à quel point l'on favorise l'évolution de $Q$ ou pas. // Il est commun de progressivement baisser $alpha$, ce qui donne lieu à des phases plus "exploratives" ($alpha$ élevé, exploration de nouvelles actions) ou "exploitative" ($alpha$ faible, exploitation des récompenses connues) #refneeded
140
+
/ Learning rate $alpha$: contrôle à quel point l'on favorise l'évolution de $Q$ ou pas.
141
141
/ Discount factor $gamma$: contrôle l'importance que l'on donne aux récompenses futures. Il est utile de commencer avec une valeur faible puis l'augmenter avec le temps @maxq-discount.
142
142
143
143
=== Difficultés liées à l'implémentation de la fonction coût
144
144
145
145
==== Tendances à la "tricherie" des agents
146
146
147
-
Expérimentalement, on sait que des tendances "tricheuses" émergent facilement pendant l'entraînement #refneeded: l'agent découvre des séries d'actions qui causent un bug avantageux vis à vis du coût associé, soit parce qu'il y a un bug dans le calcul de l'état de l'environnement post-action, soit parce que la fonction coût ne prend pas suffisemment bien en compte toutes les possibilités de l'environnement (autrement dit, il manque de contraintes).
147
+
Expérimentalement, on sait que des tendances "tricheuses" émergent facilement pendant l'entraînement: l'agent découvre des séries d'actions qui causent un bug avantageux vis à vis du coût associé, soit parce qu'il y a un bug dans le calcul de l'état de l'environnement post-action, soit parce que la fonction coût ne prend pas suffisemment bien en compte toutes les possibilités de l'environnement (autrement dit, il manque de contraintes).
148
148
149
-
Dans le cas de la robotique, cela arrive particulièrement souvent #refneeded, et il faut donc un simulateur qui soit suffisamment réaliste.
149
+
Dans le cas de la robotique, cela arrive particulièrement souvent, et il faut donc un simulateur qui soit suffisamment réaliste.
150
150
151
151
==== Sous-spécification de la fonction coût
152
152
···
170
170
#let proba = $bb(P)$
171
171
#let setbuilder = (content, with) => ${ #content thick mid(|) thick #with }$
172
172
173
-
Théoriquement, le score associé à un couple état/action est souvent réduit à l'intervalle $[0, 1]$ et assimilé à une distribution de probabilité: $Q$ est une fonction de $S times A$ vers $[0, 1]$ qui renvoie la probabilité qu'a l'agent à choisir une action en étant dans un état de l'environnement.
174
-
175
-
176
173
On note dans le reste de cette section:
177
174
178
175
/ $A$: l'ensemble des actions
···
181
178
/ $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
182
179
/ $Pi: S -> A$: une politique
183
180
/ $Pi^*: S -> A$: la meilleure politique possible, celle que l'on cherche à approcher
184
-
/ $R: S -> RR^+$: sa fonction de récompense #todo[incohérent! c'est sensé être $Q$, qu'on a assimilé à une distrib de proba :/]
181
+
/ $R: S -> RR^+$: sa fonction de récompense
185
182
/ $Q_pi: S times A -> [0, 1]$: la distribution de probabilité d'une politique $pi$, qu'on suppose Markovienne (elle ne dépend que de l'état dans lequel on est). $Q_pi (s_t, a_t)$ est la probabilité que $pi$ choisisse $a_t$, _quand on est dans l'état_ $s_t$ ($s_t$ est l'état *pré*-action, et non post-action)
186
183
/ $Q$ (resp. $Q^*$): $Q_Pi$ (resp. $Q_(Pi^*)$), pour alléger les notations
187
184
// $R$: $R_Pi$
···
283
280
284
281
285
282
[
286
-
#todo[Pas clair]
287
-
288
283
Notamment, les espérances le long d'un chemin, notées $inline(exp_(s_0, a_0, ...))$ dans @trpo, sont dénotées ici par une opération-sur-ensemble usuelle#footnote[d'autres exemples d'"opérations-sur-ensemble" sont $sum_(x in RR)$ ou $product_(n in NN)$, par exemple.], avec $exp_(c in cal(C))$. De même, la notation $inline(exp_(s_0, a_0, ... ~ pi))$ est dénotée $exp_(c ~ pi in cal(C))$ et explicitée après @eta-exp-definition.
289
284
290
285
Dans la documentation de _OpenAI Spinning Up_ (citation "@trpo-openai"), les espérances sont notées $op(E, limits: #true)_(s, a ~ pi)$, ce qui correspond à faire une espérance _le long_ de tout chemin: cela correspond ici à $exp_(c ~ pi in cal(C)) sum_(t=0)^oo dots.c$.
···
677
672
- Couple maximal sur les commandes envoyées au moteurs
678
673
- Limite sur la vélocité du robot
679
674
- Prévention des auto-collisions (par exemple, le bras qui tape la jambe)
680
-
- #todo[Ajouter @maciej]
675
+
- Limite sur les magnitudes des forces de réaction du sol @maciej
681
676
- etc.
682
677
683
678
···
731
726
scale(7%, reflow: true, diagraph.render(read("./isaac-deptree.dot"))),
732
727
)
733
728
734
-
Bien que toutes ces dépendances puissent être spécifiées avec des contraintes de version strictes @lockfiles pour éviter des changements imprévus de comportement du code venant des bibliothèques, beaucoup celles-ci ont besoin de compiler du code C++ _à l'installation_#footnote[Pour des raisons de performance @cpp-python, certaines bibliothèques implémentent leurs fonctions critiques en C++. C'est par exemple le cas de NumPy #refneeded]: fixer la version de la bibliothèque ne suffit pas donc à guarantir la reproductibilité de la compilation de l'arbre des dépendances.
729
+
Bien que toutes ces dépendances puissent être spécifiées avec des contraintes de version strictes @lockfiles pour éviter des changements imprévus de comportement du code venant des bibliothèques, beaucoup celles-ci ont besoin de compiler du code C++ _à l'installation_#footnote[Pour des raisons de performance @cpp-python, certaines bibliothèques implémentent leurs fonctions critiques en C++. C'est par exemple le cas de NumPy @numpy]: fixer la version de la bibliothèque ne suffit pas donc à guarantir la reproductibilité de la compilation de l'arbre des dépendances.
+2
-2
rapport/gz-unitree.typ
+2
-2
rapport/gz-unitree.typ
···
1
1
#import "@preview/zebraw:0.5.5"
2
2
#import "@preview/fletcher:0.5.8": diagram, edge, node
3
3
#import "@preview/cetz:0.4.2"
4
-
#import "./utils.typ": dontbreak, refneeded, trimmed-image
4
+
#import "./utils.typ": dontbreak, trimmed-image
5
5
#show figure: set block(spacing: 2em)
6
6
#let zebraw = (..args) => zebraw.zebraw(
7
7
lang: false,
···
419
419
[Respectivement $q$, $dot(q)$, $tau_"ff"$, $K_p$ et $K_d$],
420
420
)
421
421
422
-
Cette équation se rapproche des modèles de type PID (_proportional-integrative-derivative_) @control-pid, avec le terme intégratif remplacé par $tau_"ff"$, ce qui en fait une expression plus adaptée pour les politiques avec des mouvements non-brusques: le terme intégratif apporte une capacité d'instabilité qui complexifie l'entraînement #refneeded
422
+
Cette équation se rapproche des modèles de type PID (_proportional-integrative-derivative_) @control-pid, avec le terme intégratif remplacé par $tau_"ff"$, ce qui en fait une expression plus adaptée pour les politiques avec des mouvements non-brusques: le terme intégratif apporte une capacité d'instabilité qui complexifie l'entraînement
423
423
424
424
425
425
#figure(
+3
-3
rapport/nix.typ
+3
-3
rapport/nix.typ
···
1
-
#import "utils.typ": comment, refneeded, todo
1
+
#import "utils.typ": comment, todo
2
2
3
3
== Reproductibilité
4
4
···
29
29
30
30
=== Contenir les effets de bords
31
31
32
-
En dehors du besoin de vérifiabilité du monde de la recherche, la reproductibilité est une qualité recherchée dans certains domaines de programmation @reproducibility #todo[Lesquels?].
32
+
En dehors du besoin de vérifiabilité du monde de la recherche, la reproductibilité est une qualité recherchée en programmation @reproducibility.
33
33
34
-
Il existe donc depuis longtemps #todo[préciser + #refneeded] des langages de programmation dits _fonctionnels_, qui, de manière plus ou moins stricte, limitent les effets de bords. Certains langages font également la distinction entre une fonction _pure_ (sans effets de bord) et une fonction classique @fortran-pure. Certaines fonctions, plutôt appelées _procédures_, sont uniquement composées d'effet de bord et ne renvoie pas de valeur @ibm-function-procedure-routine.
34
+
Il existe donc des langages de programmation dits _fonctionnels_, qui, de manière plus ou moins stricte, limitent les effets de bords. Certains langages font également la distinction entre une fonction _pure_ (sans effets de bord) et une fonction classique @fortran-pure. Certaines fonctions, plutôt appelées _procédures_, sont uniquement composées d'effet de bord et ne renvoie pas de valeur @ibm-function-procedure-routine.
35
35
36
36
37
37
=== État dans le domaine de la robotique
+1
-1
rapport/proofs.typ
+1
-1
rapport/proofs.typ