this repo has no description
Continue rapport
+69
-13
+27
bib.yaml
+27
bib.yaml
···
476
476
url:
477
477
value: https://web.archive.org/web/20180407053740/http://neuro.cs.ut.ee/demystifying-deep-reinforcement-learning/
478
478
date: 2025-10-13
479
+
tpro:
480
+
type: article
481
+
title: Trust Region Policy Optimization
482
+
author:
483
+
- Schulman, John
484
+
- Levine, Sergey
485
+
- Moritz, Philipp
486
+
- Jordan, Michael I.
487
+
- Abbeel, Pieter
488
+
date: 2015-02
489
+
url:
490
+
value: http://arxiv.org/abs/1502.05477v5
491
+
date: '2025-10-13'
492
+
serial-number:
493
+
arxiv: 1502.05477v5
494
+
abstract: 'We describe an iterative procedure for optimizing policies, with guaranteed
495
+
monotonic improvement. By making several approximations to the theoretically-justified
496
+
procedure, we develop a practical algorithm, called Trust Region Policy Optimization
497
+
(TRPO). This algorithm is similar to natural policy gradient methods and is effective
498
+
for optimizing large nonlinear policies such as neural networks. Our experiments
499
+
demonstrate its robust performance on a wide variety of tasks: learning simulated
500
+
robotic swimming, hopping, and walking gaits; and playing Atari games using images
501
+
of the screen as input. Despite its approximations that deviate from the theory,
502
+
TRPO tends to give monotonic improvement, with little tuning of hyperparameters.'
503
+
parent:
504
+
type: periodical
505
+
+13
cite-arxiv.fish
+13
cite-arxiv.fish
+7
-7
rapport/context.typ
+7
-7
rapport/context.typ
···
1
+
#import "utils.typ": todo, comment, refneeded
1
2
#import "@preview/fletcher:0.5.8": diagram, node, edge
2
3
3
-
4
-
#let comment = content => text(fill: gray)[(Note: #content)]
5
-
#let todo = content => text(fill: red)[(TODO: #content)]
6
-
#let refneeded = text(fill: luma(100), [[Réf. nécéssaire]])
7
4
8
5
== Bases théoriques du _Reinforcement Learning_
9
6
···
180
177
181
178
=== Fonctions coût
182
179
183
-
=== Descente de gradient
180
+
=== Mise a jour
184
181
185
182
186
183
==== _Q-learning_
187
184
188
-
La récompense associée à un état $S_t$ et une action $A_t$, appelée $Q(S_t, A_t)$ ici pour "quality" @qlearning-etymology, est mise à jour ainsi @maxq:
185
+
La récompense associée à un état $S_t$ et une action $A_t$, appelée $Q(S_t, A_t)$ ici pour "quality" @qlearning-etymology, est mise à jour avec cette valeur @maxq:
189
186
190
187
$
191
-
Q(S_t, A_t) <- (1 - alpha) underbrace(Q(S_t, A_t), "valeur actuelle") + alpha ( underbrace(R_(t+1), "récompense\npour cette action") + gamma underbrace(max_a Q(S_(t+1), a), "récompense de la meilleure\naction pour l'état suivant") )
188
+
(1 - alpha) underbrace(Q(S_t, A_t), "valeur actuelle") + alpha ( underbrace(R_(t+1), "récompense\npour cette action") + gamma underbrace(max_a Q(S_(t+1), a), "récompense de la meilleure\naction pour l'état suivant") )
192
189
$
193
190
194
191
L'expression comporte deux hyperparamètres:
···
199
196
200
197
201
198
==== _Trust Region Policy Optimization_
199
+
200
+
201
+
202
202
203
203
==== _Proximal Policy Optimization_
204
204
rapport/main.pdf
rapport/main.pdf
This is a binary file and will not be displayed.
+4
rapport/main.typ
+4
rapport/main.typ
···
1
1
#import "template.typ": arkheion, arkheion-appendices, monospace
2
2
#import "utils.typ": cut-around, cut-between, dedent, include-function
3
3
4
+
#let comment = content => text(fill: gray)[(Note: #content)]
5
+
#let todo = content => text(fill: red)[(TODO: #content)]
6
+
#let refneeded = text(fill: luma(100), [[Réf. nécéssaire]])
7
+
4
8
#import "@preview/diagraph:0.3.2"
5
9
#show raw.where(lang: "dot"): it => diagraph.render(it.text)
6
10
#show raw.where(lang: "mermaid"): it => diagraph.render(
+12
-6
rapport/nix.typ
+12
-6
rapport/nix.typ
···
1
+
#import "utils.typ": todo, comment, refneeded
2
+
1
3
== Reproductibilité
2
4
3
5
=== État dans le domaine de la programmation
···
34
36
35
37
=== État dans le domaine de la robotique
36
38
37
-
En robotique, pour donner des ordres au matériel, on intéragit beaucoup avec le monde extérieur (ordres et lecture d'état de servo-moteurs, flux vidéo d'une caméra, etc), souvent dans un langage plutôt bas-niveau, pour des questions de performance et de proximité abstractionnelle au matériel
39
+
En robotique, pour donner des ordres au matériel, on intéragit beaucoup avec le monde extérieur (ordres et lecture d'état de servo-moteurs, flux vidéo d'une caméra, etc), souvent dans un langage plutôt bas-niveau, pour des questions de performance et de proximité abstractionnelle au matériel.
38
40
39
-
De fait, les langages employés sont communément C, C++ ou Python#footnote[Il arrive assez communément d'utiliser Python, un langage haut-niveau, mais c'est dans ce cas à but de prototypage, et le code contrôlant les moteurs est écrit dans un langage bas niveau plus appelé par Python par FFI] @programming-languages-robotics, des langages bien plus impératifs que fonctionnels @imperative-languages.
41
+
De fait, les langages employés sont communément C, C++ ou Python#footnote[Il arrive assez communément d'utiliser Python, un langage haut-niveau, mais c'est dans ce cas à but de prototypage, et le code contrôlant les moteurs est écrit dans un langage bas niveau puis appelé par Python par FFI.] @programming-languages-robotics, des langages bien plus impératifs que fonctionnels @imperative-languages.
40
42
41
43
L'idée de s'affranchir d'effets de bords pour rendre les programmes dans la recherche en robotique reproductibles est donc plus utopique que réaliste.
42
44
43
45
44
46
=== Environnements de développement
45
47
46
-
Cependant, ce qui fait un programme n'est pas seulement son code: surtout dans des langages plus anciens sans gestion de dépendance simple, les dépendances (bibliothèques) du programme, ainsi que l'environnement et les étapes de compilation de ce dernier, représentent également une partie considérable de la complexité du programme (par exemple, en C++, on utilise un outil générant des fichiers de configuration pour un autre outil qui à son tour configure le compilateur de C++ @cmake)
48
+
Cependant, ce qui fait un programme n'est pas seulement son code: surtout dans des langages plus anciens sans gestion de dépendance intégrée au langage, les dépendances (bibliothèques) du programme, ainsi que l'environnement et les étapes de compilation de ce dernier, représentent également une partie considérable de la complexité du programme (par exemple, en C++, on utilise un outil générant des fichiers de configuration pour un autre outil qui à son tour configure le compilateur de C++ @cmake)
47
49
48
50
C'est cette partie que Nix, le gestionnaire de paquet, permet d'encapsuler et de rendre reproductible. Dans ce modèle, la compilation (et de manière plus générale la construction, ou _build_) du projet est la fonction que l'on veut rendre pure. L'entrée est le code source, et le résultat de la fonction est un binaire, qui ne doit dépendre que du code source.
49
51
···
169
171
170
172
Lorsqu'il y a un ordinateur embarqué, comme par exemple une Raspberry Pi @raspi, il faut choisir un OS sur lequel faire tourner le programme.
171
173
172
-
La encore, un OS s'accompagne d'un amas considérable de configuration des différentes parties du système: accès au réseau, drivers,…
174
+
Là encore, un OS s'accompagne d'un amas considérable de configuration des différentes parties du système: accès au réseau, drivers,…
173
175
174
-
Sur les OS Linux classiques tels que Ubuntu ou Debian, cette configuration est parfois stockée dans des fichiers, ou parfois retenue en mémoire, modifiée par l'execution de commandes.
176
+
Sur les OS Linux classiques tels que Ubuntu ou Debian, cette configuration est parfois stockée dans des fichiers, ou parfois retenue en mémoire, modifiée par l'éxécution de commandes.
175
177
176
178
C'est un problème assez récurrent dans Linux de manière générale: d'un coup, le son ne marche plus, on passe ½h sur un forum à copier-coller des commandes dans un terminal, et le problème est réglé… jusqu'à ce qu'il survienne à nouveau après un redémarrage ou une réinstallation.
177
179
178
-
Ici, NixOS assure que toute modification de la configuration d'un système est _déclarée_ (d'où l'adjectif "déclaratif") dans des fichiers de configurations, également écrit dans des fichiers `.nix` @nixos-impatient.
180
+
Ici, NixOS assure que toute modification de la configuration d'un système est _déclarée_ (d'où l'adjectif "déclaratif") dans des fichiers de configurations, également écrits dans des fichiers `.nix` @nixos-impatient.
179
181
180
182
Ici encore, cela apporte un gain en terme de reproductibilité: l'état de configuration de l'OS sur lequel est déployé le programme du robot est, lui aussi, rendu reproductible.
183
+
184
+
== Packaging Nix pour _gz-unitree_
185
+
186
+
#todo[Faire cette partie]
+6
rapport/utils.typ
+6
rapport/utils.typ
···
1
+
#let comment = content => text(fill: gray)[(Note: #content)]
2
+
#let todo = content => text(fill: red)[(TODO: #content)]
3
+
#let refneeded = text(fill: luma(100), [[Réf. nécéssaire]])
4
+
5
+
1
6
#let cut-lines = (
2
7
starts,
3
8
ends,
···
109
114
raw(lang: lang, dedent(transform(contents)))
110
115
}
111
116
}
117
+