this repo has no description
finish ittt
+30
-15
+30
-15
biblio.typ
+30
-15
biblio.typ
···
1
1
#import "@preview/arkheion:0.1.0": arkheion, arkheion-appendices
2
+
#import "@preview/fletcher:0.5.8": diagram, edge, node
2
3
3
4
#show: arkheion.with(
4
5
title: "Étude bibliographique I",
···
7
8
),
8
9
date: "2 Septembre 2025",
9
10
abstract: [
10
-
Ce stage porte sur l'intégration de Nix et NixOS dans les processus de développement et de déploiement logiciel dans le domaine robotique au sein du LAAS. Nix, le _package manager_, et NixOS, l'OS, sont des technologies permettant une reproductibilité, une qualité importante dans le monde de la recherche.
11
+
Ce stage porte sur l'intégration de Nix et NixOS dans les processus de développement et de déploiement logiciel dans le domaine robotique au sein du LAAS. Nix, le _package manager_, et NixOS, l'OS, sont des technologies permettant une reproductibilité, une qualité importante dans le monde de la recherche.
11
12
12
13
J'ai été aussi amenée à travailler sur la création d'un _plugin_ pour Gazebo, un logiciel de simulation robotique, pour l'utiliser avec le _SDK_ d'un robot de Unitree.
13
-
]
14
+
],
14
15
)
15
16
16
17
#outline(
17
-
title: [Table des matières]
18
+
title: [Table des matières],
18
19
)
19
20
20
-
= Reproductibilité
21
+
= Reproductibilité
21
22
22
23
== État dans le domaine de la programmation
23
24
···
28
29
Mais, en contrepartie, on perd une équation qui est fondamentale en mathématiques:
29
30
30
31
$
31
-
forall E, F, forall f: E->F, forall (e_1, e_2) in E^2, e_1 = e_2 => f(e_1) = f(e_2)
32
+
forall E, F, forall f: E->F, forall (e_1, e_2) in E^2, e_1 = e_2 => f(e_1) = f(e_2)
32
33
$
33
34
34
35
En programmation, on peut très facilement construire un $f$ qui ne vérifie pas ceci:
···
91
92
else:
92
93
x = 8
93
94
return f(x)
94
-
```,
95
+
```,
95
96
```ocaml
96
97
let g x y = f (
97
-
if y = 5 then
98
-
6
99
-
else
98
+
if y = 5 then
99
+
6
100
+
else
100
101
8
101
102
)
102
103
```,
103
-
[ *Python* (`if` et `else` sont des instructions) ], [ *OCaml* (`if` et `else` forment une expression) ]
104
+
105
+
[ *Python* (`if` et `else` sont des instructions) ], [ *OCaml* (`if` et `else` forment une expression) ],
104
106
)
105
107
106
108
Afin de décrire les dépendances d'un programme, l'environnement de compilation, et les étapes pour le compiler (en somme, afin de définir le $f in "bin"^"src"$), Nix comprend un langage d'expressions @nix-language. Un fichier `.nix` définit une fonction, que Nix sait exécuter pour compiler le code source.
···
113
115
```,
114
116
```nix
115
117
{ a }: a + 3
116
-
```
118
+
```,
117
119
)
118
120
119
121
Voici un exemple de définition d'un programme, appelée _dérivation_ dans le jargon de Nix:
···
163
165
164
166
La dérivation ici prend en entrée le code source (`src-odri-masterboard-sdk`), ainsi que des dépendances, que ce soit des fonctions relatives à Nix même (comme `stdenv.mkDerivation`) pour simplifier la définition de dérivation, ou des dépendances au programmes, que ce soit pour sa compilation ou pour son exécution (dans ce dernier cas de figures, les dépendances sont inclues ou reliées au binaire final)
165
167
166
-
== Un ecosystème de dépendances
168
+
== Un ecosystème de dépendances
167
169
168
170
Afin de conserver la reproductibilité même lorsque l'on dépend de libraries tierces, ces dépendances doivent également avoir une compilation reproductible: on déclare donc des dépendances à des _packages_ Nix, disponibles sur _Nixpkgs_ @nixpkgs.
169
171
···
213
215
214
216
== `rt/lowstate`, `rt/lowcmd`
215
217
216
-
Le SDK de Unitree fonctionne via des canaux DDS, une technologie de communication temps-réel bas niveau @dds.
218
+
Le SDK de Unitree fonctionne via des canaux DDS, une technologie de communication temps-réel bas niveau @dds.
217
219
218
220
Deux de ces canaux donnent accès au contrôle (resp. à l'état) bas-niveau des moteurs (resp. capteurs) du robot: `rt/lowcmd` (resp. `rt/lowstate`).
219
221
220
222
Grâce à l'étude des paquets transmis via Wireshark, j'ai pu débugger les communications entre mon plugin, _gz-unitree_, et le SDK.
221
223
224
+
Et au final, mon plugin fonctionne, en simulant un robot H1v2 via ces deux canaux:
225
+
226
+
#align(center, diagram(
227
+
node((-1, 0))[Unitree SDKv2],
228
+
edge("->", bend: 45deg)[`rt/lowcmd`],
229
+
edge("<-", bend: -45deg)[`rt/lowstate`],
230
+
node((0, 0))[gz-unitree],
231
+
edge("<->")[`::PreUpdate`],
232
+
node((1, 0))[Gazebo],
233
+
edge("--"),
234
+
node((2, 0))[Modèle SDF du robot]
235
+
))
236
+
222
237
== Des tests end-to-end automatisés
223
238
224
-
Je souhaitais permettre de tester le code sur simulateur de manière automatique: on push un commit modifiant une politique de contrôle du robot, et, automatiquement, en CI, un test sous simulateur est lancé. On reçoit un artéfact avec une vidéo filmant le test.
239
+
Je souhaitais permettre de tester le code sur simulateur de manière automatique: on push un commit modifiant une politique de contrôle du robot, et, automatiquement, en CI, un test sous simulateur est lancé. On reçoit un artéfact avec une vidéo filmant le test.
225
240
226
241
Pour faire ceci, il a fallu rendre la fonctionnalité native à Gazebo d'enregistrement vidéo automatisable: elle ne l'est pas nativement, il a donc fallu que je duplique le code du module Gazebo correspondant, afin d'y rajouter de quoi contrôler l'entregistrement vidéo via des _topics_ Gazebo.
227
242
228
-
Il y a aussi un challenge lié au fait que, en CI, il n'y a pas d'interface graphique, ce qui rend le lancement de l'interface graphique de Gazebo impossible. Il faut donc simuler une interface graphique avec _Xvfb_ @xvfb, un serveur X virtuel.
243
+
Il y a aussi un challenge lié au fait que, en CI, il n'y a pas d'interface graphique, ce qui rend le lancement de l'interface graphique de Gazebo impossible. Il faut donc simuler une interface graphique avec _XVFB_, un serveur X virtuel @xvfb.
229
244
230
245
== Packaging sous Nix
231
246