this repo has no description
add biblio, reorganize log
+381
-97
+6
-6
.github/workflows/typst.yml
+6
-6
.github/workflows/typst.yml
···
5
5
push:
6
6
branches:
7
7
- main
8
-
paths: ["*.typst", "*.typ", ".github/workflows/typst.yml", "bib.yaml"]
8
+
paths: ["*.typ", ".github/workflows/typst.yml", "bib.yaml"]
9
9
10
10
permissions:
11
11
contents: write
···
18
18
- name: Checkout repository
19
19
uses: actions/checkout@v3
20
20
21
-
- name: Compile main
21
+
- name: Compile log
22
22
uses: lvignoli/typst-action@main
23
-
with: { source_file: main.typst }
23
+
with: { source_file: log.typ }
24
24
25
25
- name: Compile biblio
26
26
uses: lvignoli/typst-action@main
27
-
with: { source_file: biblio.typst }
27
+
with: { source_file: biblio.typ }
28
28
29
29
- name: Commit and push changes
30
30
uses: EndBug/add-and-commit@v9
31
31
with:
32
32
default_author: github_actions
33
-
message: Update main.pdf
34
-
add: main.pdf
33
+
message: Update PDFs
34
+
add: '*.pdf'
august.typst
log/august.typ
august.typst
log/august.typ
+94
bib.yaml
+94
bib.yaml
···
136
136
url:
137
137
value: https://mdipenta.github.io/files/msr2022-cps.pdf
138
138
date: 2025-07-28
139
+
140
+
nixpkgs:
141
+
type: web
142
+
url:
143
+
value: https://search.nixos.org/packages
144
+
date: 2025-09-03
145
+
146
+
nixpkgs-contributing:
147
+
type: web
148
+
title: Nixpkgs/Contributing
149
+
author: NixOS Wiki Authors
150
+
url:
151
+
value: https://wiki.nixos.org/wiki/Nixpkgs/Contributing
152
+
date: 2025-09-03
153
+
154
+
cachix:
155
+
type: web
156
+
title: Cachix — Nix binary cache hosting
157
+
url:
158
+
value: https://www.cachix.org/
159
+
date: 2025-09-03
160
+
161
+
nix-sandboxing:
162
+
type: article
163
+
title: Nix (package manager) — Sandboxing
164
+
url:
165
+
value: https://wiki.nixos.org/wiki/Nix_(package_manager)#Internals
166
+
date: 2025-09-03
167
+
168
+
purefunctions:
169
+
type: article
170
+
title: Professor Frisby’s Mostly Adequate Guide to Functional Programming
171
+
volume: 3
172
+
volume-total: 13
173
+
author: Brian Lonsdorf
174
+
publisher: Github
175
+
date: 2015
176
+
url:
177
+
value: https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md
178
+
date: 2025-09-04
179
+
180
+
reproducibility:
181
+
type: web
182
+
title: Reproducible Builds
183
+
url:
184
+
value: https://reproducible-builds.org/
185
+
date: 2025-09-04
186
+
187
+
# "ISO/IEC JTC 1/SC 22/WG5/N2137 – Fortran 2015 Committee Draft (J3/17-007r2)" (PDF). International Organization for Standardization. July 6, 2017. pp. 336–338.
188
+
fortran-pure:
189
+
type: book
190
+
title: ISO/IEC JTC 1/SC 22/WG5/N2137
191
+
author: Fortran 2015 Committee Draft (J3/17-007r2)
192
+
publisher: International Organization for Standardisation
193
+
date: 2017-07-06
194
+
page-range: 336-338
195
+
url:
196
+
value: https://wg5-fortran.org/N2101-N2150/N2137.pdf
197
+
date: 2025-09-04
198
+
199
+
ibm-function-procedure-routine:
200
+
type: article
201
+
title: Relationship Between Routines, Functions, and Procedures
202
+
publisher: IBM
203
+
date: 2025-01-13
204
+
url:
205
+
value: https://www.ibm.com/docs/en/informix-servers/15.0.0?topic=statement-relationship-between-routines-functions-procedures
206
+
date: 2025-09-04
207
+
208
+
programming-languages-robotics:
209
+
type: article
210
+
title: Different Types of Robot Programming Languages
211
+
publisher: Plant Automation Technology
212
+
date: 2015
213
+
url:
214
+
value: https://www.plantautomation-technology.com/articles/different-types-of-robot-programming-languages
215
+
date: 2025-09-04
216
+
217
+
imperative-languages:
218
+
type: article
219
+
title: "Imperative programming: Overview of the oldest programming paradigm"
220
+
publisher: IONOS
221
+
date: 2021-05-21
222
+
url:
223
+
value: https://www.ionos.com/digitalguide/websites/web-development/imperative-programming/
224
+
date: 2025-09-04
225
+
226
+
github-runners:
227
+
type: article
228
+
title: GitHub-hosted runners
229
+
publisher: Github
230
+
url:
231
+
value: https://docs.github.com/en/actions/concepts/runners/github-hosted-runners
232
+
date: 2025-09-04
+201
biblio.typ
+201
biblio.typ
···
1
+
#import "@preview/arkheion:0.1.0": arkheion, arkheion-appendices
2
+
3
+
#let citneeded = super([[réf. nécéssaire]])
4
+
5
+
#show: arkheion.with(
6
+
title: "Étude bibliographique I",
7
+
authors: (
8
+
(name: "Gwenn Le Bihan", email: "gwenn.lebihan@etu.inp-n7.fr", affiliation: "ENSEEIHT"),
9
+
),
10
+
date: "2 Septembre 2025",
11
+
abstract: [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]
12
+
)
13
+
14
+
#outline(
15
+
title: [Table des matières]
16
+
)
17
+
18
+
= Reproductibilité
19
+
20
+
== État dans le domaine de la programmation
21
+
22
+
La différence entre une fonction au sens mathématique et une fonction au sens programmatique consiste en le fait que, par des raisons de practicité, on permet aux `function`s des langages de programmation d'avoir des _effets de bords_. Ces effets affectent, modifient ou font dépendre la fonction d'un environnement global qui n'est pas explicitement déclaré comme une entrée (un argument) de la fonction en question @purefunctions.
23
+
24
+
Cette liberté permet, par exemple, d'avoir accès à la date et à l'heure courante, interagir avec un système de fichier d'un ordinateur, générer une surface pseudo aléatoire par bruit de Perlin, etc.
25
+
26
+
Mais, en contrepartie, on perd une équation qui est fondamentale en mathématiques:
27
+
28
+
$
29
+
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)
30
+
$
31
+
32
+
En programmation, on peut très facilement construire un $f$ qui ne vérifie pas ceci:
33
+
34
+
```python
35
+
from datetime import date
36
+
37
+
def f(a):
38
+
return date.today().year + a
39
+
```
40
+
41
+
Selon l'année dans laquelle nous sommes, $mono(f)(0)$ n'a pas la même valeur.
42
+
43
+
De manière donc très concrète, si cette fonction `f` fait partie du protocole expérimental d'une expérience, cette expérience n'est plus reproductible, et ses résultats sont donc potentiellement non vérifiables, si le papier est soumis le 15 décembre 2025 et la _peer review_ effectuée le 2 janvier 2026.
44
+
45
+
== Contenir les effets de bords
46
+
47
+
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
48
+
49
+
Il existe donc depuis longtemps des langages de programmation dits _fonctionnels_, qui, de manière plus ou moins stricte, limite les effets de bords. Certains langages font également la distinction entre une fonction _pure_#footnote[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 puisqu'elle ne renvoie pas de valeur @ibm-function-procedure-routine
50
+
51
+
52
+
== État dans le domaine de la robotique
53
+
54
+
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
55
+
56
+
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.
57
+
58
+
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.
59
+
60
+
61
+
== Environnements de développement
62
+
63
+
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.
64
+
65
+
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.
66
+
67
+
$
68
+
forall "src", "bin", forall f in "bin"^"src", forall (P_1, P_2) in "src"^2, P_1 = P_2 => f(P_1) = f(P_2)
69
+
$
70
+
71
+
Ici, $P_1$ et $P_2$ sont deux itérations du code source (src) du programme. Si le code source est identique, les binaires résultants de la compilation ($f$) sont égaux, au sens de l'égalité bit à bit.
72
+
73
+
On a la proposition (1), avec $E = "src"$, l'ensemble des code source possibles pour un langage, et $F= "bin"$, l'ensemble des binaires éxécutables
74
+
75
+
Nix ne peut pas garantir que le programme sera sans effets de bords au _runtime_, mais vise à le garantir au _build-time_.
76
+
77
+
= Nix, le gestionnaire de paquets pur
78
+
79
+
== Un _DSL_#footnote[Domain-Specific Language] fonctionnel
80
+
81
+
Une autre caractéristique que l'on trouve souvent dans la famille de langages fonctionnels est l'omniprésence des _expressions_: quasi toute les constructions syntaxiques forment des expressions valides, et peuvent donc servir de valeur
82
+
83
+
#table(
84
+
columns: (50%, 50%),
85
+
```python
86
+
def g(x, y):
87
+
if y == 5:
88
+
x = 6
89
+
else:
90
+
x = 8
91
+
return f(x)
92
+
```,
93
+
```ocaml
94
+
let g x y = f (
95
+
if y = 5 then
96
+
6
97
+
else
98
+
8
99
+
)
100
+
```,
101
+
[ *Python* (`if` et `else` sont des instructions) ], [ *OCaml* (`if` et `else` forment une expression) ]
102
+
)
103
+
104
+
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.
105
+
106
+
#table(
107
+
columns: (50%, 50%),
108
+
table.header([Expression d'une fonction en Python], [En Nix]),
109
+
```python
110
+
lambda f(a): a + 3
111
+
```,
112
+
```nix
113
+
{ a }: a + 3
114
+
```
115
+
)
116
+
117
+
Voici un exemple de définition d'un programme, appelée _dérivation_ dans le jargon de Nix:
118
+
119
+
120
+
```nix
121
+
{
122
+
src-odri-masterboard-sdk,
123
+
124
+
lib,
125
+
stdenv,
126
+
jrl-cmakemodules,
127
+
cmake,
128
+
python3Packages,
129
+
catch2_3,
130
+
}:
131
+
132
+
stdenv.mkDerivation {
133
+
pname = "odri_master_board_sdk";
134
+
version = "1.0.7";
135
+
136
+
src = src-odri-masterboard-sdk;
137
+
138
+
preConfigure = ''
139
+
cd sdk/master_board_sdk
140
+
'';
141
+
142
+
doCheck = true;
143
+
144
+
cmakeFlags = [
145
+
(lib.cmakeBool "BUILD_PYTHON_INTERFACE" stdenv.hostPlatform.isLinux)
146
+
];
147
+
148
+
nativeBuildInputs = [
149
+
jrl-cmakemodules
150
+
python3Packages.python
151
+
cmake
152
+
];
153
+
154
+
buildInputs = with python3Packages; [ numpy ];
155
+
156
+
nativeCheckInputs = [ catch2_3 ];
157
+
158
+
propagatedBuildInputs = with python3Packages; [ boost ];
159
+
}
160
+
```
161
+
162
+
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)
163
+
164
+
== Un ecosystème de dépendances
165
+
166
+
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.
167
+
168
+
Parfois donc, écrire un paquet Nix pour son logiciel demande aussi d'écrire les paquets Nix pour les dépendances de notre projet, si celles-ci n'existent pas encore, et cela récursivement. On peut ensuite soumettre nos paquets afin que d'autres puissent en dépendre sans les réécrire, en contribuant à _Nixpkgs_ @nixpkgs-contributing
169
+
170
+
Pour ne pas avoir à compiler toutes les dépendances soit-même quand on dépend de `.nix` de _nixpkgs_, il existe un serveur de cache, qui propose des binaires des dépendances, Cachix @cachix
171
+
172
+
== Une compilation dans un environnement fixé
173
+
174
+
Certains aspects de l'environnement dans lequel l'on compile un programme peuvent faire varier le résultat final. Pour éviter cela, Nix limite au maximum les variations d'environnement. Par exemple, la date du système est fixée au 0 UNIX (1er janvier 1990): le programme compilé ne peut pas dépendre de la date à laquelle il a été compilé.
175
+
176
+
Quand le _sandboxing_ est activé, Nix isole également le code source de tout accès au réseau, aux autres fichiers du système (ainsi que d'autres mesures) pour améliorer la reproductibilité @nix-sandboxing
177
+
178
+
=== Un complément utile: compiler en CI
179
+
180
+
Pour aller plus loin, on peut lancer la compilation du paquet Nix en _CI_#footnote[Continuous Integration, lit. intégration continue], c'est-à-dire sur un serveur distant au lieu de sur sa propre machine. On s'assure donc que l'état de notre machine de développement personnelle n'influe pas sur la compilation, puisque chaque compilation est lancée dans une machine virtuelle vierge @github-runners.
181
+
182
+
= NixOS, un système d'exploitation à configuration déclarative
183
+
184
+
Une fois le programme compilé avec ses dépendances, il est prêt à être transféré sur l'ordinateur ou la carte de contrôle embarquée au robot.
185
+
186
+
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.
187
+
188
+
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,…
189
+
190
+
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.
191
+
192
+
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.
193
+
194
+
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`.
195
+
196
+
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.
197
+
198
+
199
+
200
+
201
+
#bibliography("bib.yaml")
-11
biblio.typst
-11
biblio.typst
···
1
-
= E'tude bibliographique
2
-
3
-
== Introduction
4
-
5
-
Mon stage porte sur l'intégration de Nix @nix et NixOS @nixos dans le processus du développement et déploiement des politiques de contrôle de robots du laboratoire du LAAS-CNRS, au sein de l'équipe Gepetto.
6
-
7
-
J'ai assez vite été chargée d'une autre mission s'incluant dans l'amélioration du processus de développement, qui consiste en la création d'un plugin Gazebo @gazebo. Ce plugin permet au SDK de Unitree @unitree_sdk2, le SDK des robots de la companie, d'envoyer des ordres à Gazebo, un logiciel de simulation.
8
-
9
-
Le but est d'en suite faire tourner de tests en simulateur
10
-
11
-
#bibliography("bib.yaml")
-27
july.typst
-27
july.typst
···
1
-
=== 30 Juin - 4 Juillet
2
-
3
-
- Continuation du travail: essais pour rajouter un capteur IMU sur le robot, essais pour faire fonctionner l'auto-collision
4
-
5
-
=== 7-11 Juillet
6
-
7
-
- Capteur IMU rajouté
8
-
- Ajout du tick (temps) de simulation
9
-
- Essais d'utilisation de gz-unitree avec les politiques RL#footnote[Reinforcement Learning] de Gepetto
10
-
11
-
=== 14-18 Juillet
12
-
13
-
- Tentatives d'amélioration des performances pour améliorer le RTF: passage de 10% à 15%
14
-
- Parallélisation de l'envoi des messages des DDS dans un thread différent du principal
15
-
- Optimisations classiques
16
-
17
-
- Ecriture d'une recette _Just_ @justfile pour configurer l'environnement de développement, sur Arch Linux ou Ubuntu
18
-
- Reproduction des résultats sur un OS et une machine différente
19
-
20
-
=== 21-25 Juillet
21
-
22
-
- Évaluation de `gazebo-sim-overlay` @gazebo-sim-overlay comme solution pour un packaging Nix
23
-
- Recherche sur un mode headless de gazebo suite à des erreurs de QT sous devshell Nix
24
-
25
-
=== 28 Juillet - 1 août
26
-
27
-
- Recherche autour de l'utilisation de Gazebo dans des environnements CI/CD @msr2022-cps, en particulier pour capturer une simulation en vidéo
-24
june.typst
-24
june.typst
···
1
-
=== 2-6 Juin
2
-
3
-
- Début de recherches sur l'installation de NixOS sur Raspberry Pi @raspi 400 et 5
4
-
- Flash du firmware master-board sur un testbench
5
-
- Test du packaging de odri_control_interface @odri-controls avec les scripts de démos à l'aide d'un testbench
6
-
- Début de recherches sur la création d'un plugin Gazebo @gazebo communiquant avec la couche bas niveau du SDK2 @unitree_sdk2 d'Unitree afin de simuler du code pour le robot H1 @h1 dans Gazebo
7
-
8
-
=== 9-13 Juin
9
-
10
-
- Progrès sur l'accès à la couche bas niveau du SDK2 @unitree_sdk2
11
-
- Analyse via Wireshark des paquets
12
-
- Analyse du code source du plugin Mujoco @mujoco fourni par Unitree
13
-
14
-
=== 16-20 Juin
15
-
16
-
- Réussite de l'accès à la couche bas niveau du SDK2 via les définitions IDL @omgidl fournies par Unitree
17
-
- Documentation sur le système de plugins de Gazebo @gazebo
18
-
- Début de travail sur le bridge Gazebo/unitree: `gz-unitree`
19
-
- Implémentation de la communication DDS @dds entre un binaire d'exemple d'utilisation du SDK2 et le plugin Gazebo
20
-
21
-
=== 23-27 Juin
22
-
23
-
- Construction du _lowstate_ à envoyer au SDK2 depuis _gz-unitree_:
24
-
- Utilisation du modèle SDF @sdf du robot H1-2 @h1v2 au lieu de H1 @h1, ajout d'un sol au monde du SDF
+9
log.typ
+9
log.typ
+27
log/july.typ
+27
log/july.typ
···
1
+
=== 30 Juin - 4 Juillet
2
+
3
+
- Continuation du travail: essais pour rajouter un capteur IMU sur le robot, essais pour faire fonctionner l'auto-collision
4
+
5
+
=== 7-11 Juillet
6
+
7
+
- Capteur IMU rajouté
8
+
- Ajout du tick (temps) de simulation
9
+
- Essais d'utilisation de gz-unitree avec les politiques RL#footnote[Reinforcement Learning] de Gepetto
10
+
11
+
=== 14-18 Juillet
12
+
13
+
- Tentatives d'amélioration des performances pour améliorer le RTF: passage de 10% à 15%
14
+
- Parallélisation de l'envoi des messages des DDS dans un thread différent du principal
15
+
- Optimisations classiques
16
+
17
+
- Ecriture d'une recette _Just_ @justfile pour configurer l'environnement de développement, sur Arch Linux ou Ubuntu
18
+
- Reproduction des résultats sur un OS et une machine différente
19
+
20
+
=== 21-25 Juillet
21
+
22
+
- Évaluation de `gazebo-sim-overlay` @gazebo-sim-overlay comme solution pour un packaging Nix
23
+
- Recherche sur un mode headless de gazebo suite à des erreurs de QT sous devshell Nix
24
+
25
+
=== 28 Juillet - 1 août
26
+
27
+
- Recherche autour de l'utilisation de Gazebo dans des environnements CI/CD @msr2022-cps, en particulier pour capturer une simulation en vidéo
+24
log/june.typ
+24
log/june.typ
···
1
+
=== 2-6 Juin
2
+
3
+
- Début de recherches sur l'installation de NixOS sur Raspberry Pi @raspi 400 et 5
4
+
- Flash du firmware master-board sur un testbench
5
+
- Test du packaging de odri_control_interface @odri-controls avec les scripts de démos à l'aide d'un testbench
6
+
- Début de recherches sur la création d'un plugin Gazebo @gazebo communiquant avec la couche bas niveau du SDK2 @unitree_sdk2 d'Unitree afin de simuler du code pour le robot H1 @h1 dans Gazebo
7
+
8
+
=== 9-13 Juin
9
+
10
+
- Progrès sur l'accès à la couche bas niveau du SDK2 @unitree_sdk2
11
+
- Analyse via Wireshark des paquets
12
+
- Analyse du code source du plugin Mujoco @mujoco fourni par Unitree
13
+
14
+
=== 16-20 Juin
15
+
16
+
- Réussite de l'accès à la couche bas niveau du SDK2 via les définitions IDL @omgidl fournies par Unitree
17
+
- Documentation sur le système de plugins de Gazebo @gazebo
18
+
- Début de travail sur le bridge Gazebo/unitree: `gz-unitree`
19
+
- Implémentation de la communication DDS @dds entre un binaire d'exemple d'utilisation du SDK2 et le plugin Gazebo
20
+
21
+
=== 23-27 Juin
22
+
23
+
- Construction du _lowstate_ à envoyer au SDK2 depuis _gz-unitree_:
24
+
- Utilisation du modèle SDF @sdf du robot H1-2 @h1v2 au lieu de H1 @h1, ajout d'un sol au monde du SDF
+20
log/may.typ
+20
log/may.typ
···
1
+
=== 19-23 Mai
2
+
3
+
- Mise en place de l'environnement de développement
4
+
- Documentation sur Nix le langage @nix-language
5
+
- Découverte de la description d'une dérivation @nix-derivation et d'un flake
6
+
- Découverte de l'infrastructure autour de nixpkgs (github, la CI, Hydra @hydra...)
7
+
- Packaging en flake et CI basique (`nix build`) de `open-dynamic-robot-initiative/{interface_controls,master-board}` @odri-controls, @odri-masterboard
8
+
- Début du travail de packaging de `open-dynamic-robot-initiative/robot_properties_solo`
9
+
- Migration de `robot_properties_solo` vers uv @uv
10
+
- Début du packaging de `xacro` sur NixOS/nixpkgs @nixpkgs-xacro
11
+
- Création d'un JSON Schema @json-schema pour des fichiers de configuration de `robot_properties_solo` et mise en place d'une CI pour les valider @odri-properties-solo
12
+
- Recherche autour d'une potentielle validation au runtime en C++ des fichiers de config par le JSON Schema
13
+
- Découverte des overlays Nix
14
+
15
+
=== 26-28 Mai
16
+
17
+
- Continuation du travail précédent
18
+
19
+
20
+
main.pdf
main.pdf
This is a binary file and will not be displayed.
-9
main.typst
-9
main.typst
-20
may.typst
-20
may.typst
···
1
-
=== 19-23 Mai
2
-
3
-
- Mise en place de l'environnement de développement
4
-
- Documentation sur Nix le langage @nix-language
5
-
- Découverte de la description d'une dérivation @nix-derivation et d'un flake
6
-
- Découverte de l'infrastructure autour de nixpkgs (github, la CI, Hydra @hydra...)
7
-
- Packaging en flake et CI basique (`nix build`) de `open-dynamic-robot-initiative/{interface_controls,master-board}` @odri-controls, @odri-masterboard
8
-
- Début du travail de packaging de `open-dynamic-robot-initiative/robot_properties_solo`
9
-
- Migration de `robot_properties_solo` vers uv @uv
10
-
- Début du packaging de `xacro` sur NixOS/nixpkgs @nixpkgs-xacro
11
-
- Création d'un JSON Schema @json-schema pour des fichiers de configuration de `robot_properties_solo` et mise en place d'une CI pour les valider @odri-properties-solo
12
-
- Recherche autour d'une potentielle validation au runtime en C++ des fichiers de config par le JSON Schema
13
-
- Découverte des overlays Nix
14
-
15
-
=== 26-28 Mai
16
-
17
-
- Continuation du travail précédent
18
-
19
-
20
-
november.typst
log/november.typ
november.typst
log/november.typ
september.typst
log/september.typ
september.typst
log/september.typ