this repo has no description
Continue rapport
+34
-17
+9
bib.yaml
+9
bib.yaml
+25
-17
rapport/context.typ
+25
-17
rapport/context.typ
···
36
36
37
37
/ Agent: Robot pour lequel on développe le programme de contrôle (appelée une _politique_)
38
38
/ Actions: Envoi d'ordres aux moteurs // #footnote[il y a techniquement deux principales manières de contrôler un robot: l'envoi de commandes de courant, ou contrôle par puissance, et l'envoi de vitesses cibles, qui laisse la détermination du courant nécéssaire au microcontrolleurs sur le robot même]
39
-
/ Environnement: Le monde réel. C'est de loin la partie la plus difficile à simuler informatiquement. On utilise des moteurs de simulation physique, dont la multiplicité des implémentations est importante, voir @simulators
39
+
/ Environnement: Le monde réel. C'est de loin la partie la plus difficile à simuler informatiquement. On utilise des moteurs de simulation physique, dont la multiplicité des implémentations est importante, voir @why_multiple_simulators
40
40
/ Coût: un ensemble de contraintes ("ne pas endommager le robot"), dont la plupart dépendent de l'objectif de la politique
41
41
42
42
=== L'entraînement
···
109
109
110
110
Un exemple populaire est l'expérience de pensée du Maximiseur de trombones @trombones: un agent avec pour environnement le monde réel, pour actions "prendre des décisions"; "envoyer des emails"; etc. et pour fonction récompense (une fonction à maximiser au lieu de minimiser) "le nombre de trombones existant sur Terre", finirait possiblement par réduire en escalavage tout être vivant capable de produire des trombones: la fonction coût est sous-spécifiée
111
111
112
-
==== Bug dans un moteur de physique
112
+
==== Bug dans l'implémentation de l'environnement
113
113
114
-
Dans le contexte de la robotique, le calcul de l'état post-action de l'environnement est le travail du _moteur de physique_.
115
114
116
-
Bien évidemment, ce sont des programmes complexes avec souvent des résolutions numériques d'équation physiques, il est presque inévitable que des bugs se glissent dans ces programmes.
115
+
Bien évidemment, pour l'agent, tant qu'un bug n'est pas explicitement découragé par sa prise en compte dans la fonction coût. Si une action est favorable à l'amélioration du score, l'agent la prendra.
117
116
118
-
Ces phénomènes, appelés _"glitches"_ dans le jargon du jeu vidéo, peuvent se manifester de diverses manières:
119
117
120
-
#comment[ Compliqué sans vidéo... ptet à remplacer par une phrase seulement, ou alors c'est peut-être déjà assez clair sans exemples? ]
118
+
==== La validation comme méthode de mitigation <why_multiple_simulators>
119
+
#comment[ça se dit mitigation en français?]
121
120
122
-
- Le passage à travers un objet solide à cause de cas limites dans les calculs de collision joueur-objet (appelé _No clip_)
123
-
- La téléportation du joueur sur des grandes distances sans cause raisonnable, souvent causé par des erreurs dans le calcul des coordonnées de sa position
124
-
- La projection d'un objet a une vitesse extrême, souvent causé par des cas limites dans le calcul de la vélocité lors d'une collision
121
+
Comme ces bugs sont des comportements non voulus, il est très probables qu'ils ne soient pas exactement les mêmes d'implémentation à implémentation du même environnement.
125
122
126
-
Bien évidemment, pour l'agent, tant qu'un bug n'est pas explicitement découragé par sa prise en compte dans la fonction coût, si l'état résultant améliore le score, l'agent apprendra à faire cette action quand c'est utile.
123
+
Il convient donc de se servir de _plusieurs_ implémentations: un sert à la phase d'entraînement, pendant laquelle l'agent développe des "tendances à la tricherie", puis une phase de _validation_.
127
124
128
-
#comment[ Rien à voir mais je me dis, c'est enfait un moyen de trouver des bugs dans un physics engine ! ça me fait penser au Fuzzing un peu, mais avec un NN plutôt que du hasard contrôlé ]
125
+
Cette phase consiste en le lancement de l'agent dans une autre implémentation, avec les mêmes actions mais qui, crucialement, ne comporte pas les mêmes bugs que l'environnement ayant servi à la phase d'apprentissage.
129
126
130
-
==== La validation comme méthode de mitigation
131
-
#comment[ça se dit mitigation en français?]
127
+
Les "techniques de triche" ainsi apprises deviennent inefficace, et si le score (le coût ou la récompense) devient bien pire que pendant l'apprentissage, on peut détecter les cas de triche.
132
128
129
+
On peut même aller plus loin, et multiplier les phases de validation avec des implémentations supplémentaires, ce qui réduit encore la probabilité qu'une technique de triche se glisse dans l'agent final
133
130
131
+
#comment[ Rien à voir mais je me dis, c'est enfait un moyen de trouver des bugs dans un physics engine ! ça me fait penser au Fuzzing un peu, mais avec un NN plutôt que du hasard contrôlé ]
134
132
135
133
136
134
== Application en robotique
137
135
138
-
== Le H1v2 d'_Unitree_
139
136
140
-
== Environnements et moteurs de simulation physique <simulators>
137
+
Dans le contexte de la robotique, le calcul de l'état post-action de l'environnement est le travail du _moteur de physique_.
141
138
142
-
=== MuJoCo
139
+
Bien évidemment, ce sont des programmes complexes avec souvent des numériques souvent numériques d'équation physiques; il est presque inévitable que des bugs se glissent dans ces programmes.
140
+
141
+
Il existe plusieurs moteurs de physique
143
142
144
-
=== Gazebo
143
+
=== Simulateurs
144
+
145
+
==== MuJoCo
146
+
147
+
==== Gazebo
148
+
149
+
=== Moteurs de simulation physique
150
+
151
+
152
+
== Le H1v2 d'_Unitree_
145
153
146
154
== Reproductibilité logicielle
rapport/main.pdf
rapport/main.pdf
This is a binary file and will not be displayed.