+11 -1

bib.yaml

reviewed

··· 916 916 gzu-ghcr: 917 917 type: repository 918 918 title: 'Package gz-unitree' 919 919 - author: Gepetto 919 919 + author: Gepetto team at LAAS-CNRS 920 920 publisher: Github 921 921 url: 922 922 date: '2025-10-28' ··· 1101 1101 url: 1102 1102 date: 2025-11-03 1103 1103 value: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+gz+author%3AGuelakais 1104 1104 + h1v2isaac: 1105 1105 + type: repository 1106 1106 + title: h1v2-Isaac 1107 1107 + publisher: GitHub 1108 1108 + author: Gepetto team at LAAS-CNRS 1109 1109 + url: 1110 1110 + date: '2025-11-05' 1111 1111 + value: https://github.com/Gepetto/h1v2-Isaac 1112 1112 + date: '2025-06-02' 1113 1113 +

+19 -38

rapport/context.typ

reviewed

··· 468 468 469 469 470 470 471 471 - La méthode TRPO définit la mise à jour de $Q$ avec un $Q'$ qui maximise le _surrogate advantage_ @trpo-openai, sous une contrainte limitant l'écart entre $Q$ et $Q'$ 472 472 - 473 473 - 474 474 - L'idée de la _TRPO_ est de maximiser le _surrogate advantage_ du nouveau $Q$ tout en limitant l'ampleur des modifications apportées à $Q$, ce qui procure une stabilité à l'algorithme, et évite qu'un seul "faux pas" dégrade violemment la performance de la politique. 471 471 + La méthode TRPO définit la mise à jour de $Q$ avec un $Q'$ qui maximise le _surrogate advantage_ @trpo-openai, sous une contrainte limitant l'ampleur des modifications individuelles, ce qui procure une stabilité à l'algorithme, et évite qu'un seul "faux pas" dégrade violemment la performance de la politique. 475 472 476 473 $ 477 474 Q' = & cases( ··· 494 491 495 492 496 493 497 497 - Pour évaluer cette distance, on regarde la plus grande des distances entre des paires de distributions de probabilité de politiques $Q_Pi$ et $Q_Pi'$ pour $s in S$ fixé @trpo 494 494 + Pour évaluer cette distance, on regarde la plus grande des distances entre des paires de distributions de probabilité de politiques $Q_Pi$ et $Q_Pi'$, pour tout $s in S$ @trpo 498 495 499 496 $ 500 497 max_(s in S) D_"KL" (Q_Pi' (s, dot) || Q_Pi (s, dot)) < delta ··· 536 533 537 534 #let ddot = [ #sym.dot #h(-1em / 16) #sym.dot ] 538 535 539 539 - En pratique, l'optimisation sous cette contrainte est trop demandeuse en puissance de calcul, on utilise plutôt l'espérance @trpo 536 536 + #dontbreak[ 537 537 + 538 538 + En pratique, l'optimisation sous cette contrainte est trop demandeuse en puissance de calcul, on utilise plutôt l'espérance @trpo. 540 539 541 540 $ 542 541 overline(D_"KL") := bb(E)_(s in S) D_"KL" (Q(s, dot) || Q'(s, dot)) 543 542 $ 544 543 544 544 + ] 545 545 546 546 547 547 ··· 663 663 664 664 ] 665 665 666 666 - == CaT (_Constraints as Terminations_) 667 667 - 668 668 - // L'algorithme de mise à jour est le suivant @ppo-openai: 669 669 - // 670 670 - // 1. Mise à jour de la politique: 671 671 - // 672 672 - // $ 673 673 - // Pi' = argmax_p 1/T sum_(t=1)^T L(s, a, Pi, p, R) 674 674 - // $ 675 675 - 676 666 677 667 == Application en robotique 678 668 679 669 680 680 - Dans le contexte de la robotique, le calcul de l'état post-action de l'environnement est le travail du _moteur de physique_. 681 681 - 682 682 - Bien évidemment, ce sont des programmes complexes avec des résolutions souvent numériques d'équation physiques; il est presque inévitable que des bugs se glissent dans ces programmes. 683 683 - 684 684 - Un environnement de RL#footnote[Reinforcement Learning] ne se résume pas à son moteur de physique: il faut également charger des modèles 3D, le modèle du robot (qui doit être contrôlable par les actions, on fait donc une émulation de la partie logicielle du robot), et également, pendant les phases de développement, avoir un moteur de rendu graphique, une interface et des outils de développement. 685 685 - 686 686 - Cet ensemble s'appelle un _simulateur système_. 687 687 - 688 688 - 689 670 === Spécification de la tâche 690 671 691 672 Le score (récompense ou coût) dépend de la tâche pour laquelle on veut entraîner l'agent. ··· 700 681 701 682 702 683 === Inventaire des simulateurs en robotique 684 684 + 685 685 + 686 686 + Dans le contexte de la robotique, le calcul de l'état post-action de l'environnement est le travail du _moteur de physique_. 687 687 + 688 688 + Bien évidemment, ce sont des programmes complexes avec des résolutions souvent numériques d'équation physiques; il est presque inévitable que des bugs se glissent dans ces programmes. 689 689 + 690 690 + 691 691 + 692 692 + 693 693 + Un environnement de RL#footnote[Reinforcement Learning] ne se résume pas à son moteur de physique: il faut également charger des modèles 3D, le modèle du robot (qui doit être contrôlable par les actions, on fait donc une émulation de la partie logicielle du robot), et également, pendant les phases de développement, avoir un moteur de rendu graphique, une interface et des outils de développement. 694 694 + 695 695 + Cet ensemble s'appelle un _simulateur système_. 703 696 704 697 ==== Isaac 705 698 ··· 726 719 / Bullet Featherstone: Plugin `gz-physics-bullet-featherstone-plugin`, également en beta @gazebo-physics-engines. Une variable de Bullet, utilisant l'algorithme de Featherstone @bullet-featherstone @featherstone 727 720 728 721 729 729 - == Le robot _H1v2_ d'Unitree 730 730 - 731 731 - _H1v2_ est un modèle de robot humanoïde créé par la société Unitree. 732 732 - 733 733 - Il possède plus de 26 degrés de liberté, dont 734 734 - 735 735 - - 6 dans chaque jambe (3 à la hanche, 2 au talon et un au genou), 736 736 - - 7 dans chaque bras (3 à l'épaule, 3 au poignet et un au coude) @h1v2 737 737 - 738 738 - 739 722 == Reproductibilité logicielle 740 723 741 724 La reproductibilité est particulièrement complexe dans le champ du reinforcement learning @rl-reproducibility. ··· 747 730 scale(7%, reflow: true, diagraph.render(read("./isaac-deptree.dot"))), 748 731 ) 749 732 750 750 - Bien que toutes ces dépendances puissent être spécifiées à des versions 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 pour des raisons de performance @cpp-python. 751 751 - 752 752 - Des problèmes de reproductibilité peuvent donc subsister à l'installation des dépendances, étant donné la dépendance du processus de compilation à la machine compilant le code. 733 733 + 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.

+7 -7

rapport/gz-unitree.typ

reviewed

··· 715 715 }) 716 716 717 717 718 718 - Ici également, `LowStateWriter` s'exécute _en parallèle_ du code de `::PreUpdate`: En effet, la création du `ChannelPublisher` démarre une boucle qui vient éxécuter `LowStateWriter` périodiquement, dans un autre _thread_: on a donc aucune garantie de synchronisation entre les deux. 718 718 + Ici également, `LowStateWriter` s'exécute _en parallèle_ du code de `::PreUpdate`: En effet, la création du `ChannelPublisher` démarre une boucle qui vient exécuter `LowStateWriter` périodiquement, dans un autre _thread_: on a donc aucune garantie de synchronisation entre les deux. 719 719 720 720 Ici, il y a en plus non pas deux, mais _cinq_ boucles indépendantes qui sont en jeux: 721 721 ··· 866 866 867 867 == Amélioration des performances <perf> 868 868 869 869 - Les premiers essais affichent un facteur temps-réel#footnote[Appelé RTF @rtf (Real-Time Factor). Un RTF de 100% signifie que la simulation s'éxécute à vitesse réelle, un RTF inférieur à 1 signifie que la simulation est plus lente que la vitesse simulée] autour des 10 à 15%. 869 869 + Les premiers essais affichent un facteur temps-réel#footnote[Appelé RTF @rtf (Real-Time Factor). Un RTF de 100% signifie que la simulation s'exécute à vitesse réelle, un RTF inférieur à 1 signifie que la simulation est plus lente que la vitesse simulée] autour des 10 à 15%. 870 870 871 871 #grid( 872 872 columns: 2, ··· 929 929 Ainsi que d'autres optimisations, qui ne sont pas en rapport avec cette phase d'un cycle: 930 930 931 931 / Mise en cache de joints à l'initialisation du plugin: pour éviter de devoir appeler `model.JointByName` dans une _hot loop_#footnote[Boucle (`for` ou `while`) dont le corps est exécuté un très grand nombre de fois, et dont la rapidité est importante]. 932 932 - / Utilisation d'une implémentation de CRC32 plus rapide: tentative avec _CRC++_ @crcpp non achevée, à cause d'un _stack smashing_ pendant l'éxécution 932 932 + / Utilisation d'une implémentation de CRC32 plus rapide: tentative avec _CRC++_ @crcpp non achevée, à cause d'un _stack smashing_ pendant l'exécution 933 933 934 934 935 935 Après optimisations, on arrive à atteindre un RTF aux alentours des 30%. Des recherches supplémentaires sont nécéssaires pour atteindre un RTF raisonnable. ··· 980 980 981 981 Une fois l'enregistrement vidéo rendu automatisable, si l'on veut mettre en place le lancement automatique à chaque commit du dépôt git de la politique (i.e. chaque changement de la politique), il faut crééer une description de _workflow_ (dans notre cas, un workflow _Github Actions_). 982 982 983 983 - Un workflow est un ensemble de commandes à exécuter dans un environnement virtualisé (qu'il s'agisse d'une machine virtuelle ou d'un simple container), ainsi que des évènements et conditions décrivant quand lancer l'éxécution (par exemple, "à chaque commit sur la branche `main`"). C'est un des outils permettant de mettre en place la CI/CD. 983 983 + Un workflow est un ensemble de commandes à exécuter dans un environnement virtualisé (qu'il s'agisse d'une machine virtuelle ou d'un simple container), ainsi que des évènements et conditions décrivant quand lancer l'exécution (par exemple, "à chaque commit sur la branche `main`"). C'est un des outils permettant de mettre en place la CI/CD. 984 984 985 985 === Une image de base avec Docker 986 986 987 987 - L'environnement d'éxécution des workflows ne comporte pas d'installation de Gazebo. Étant donné le temps de compilation élevé, on peut "factoriser" cette étape dans une _image de base_, de laquelle on démarre pour chaque éxécution du workflow, dans laquelle tout les programmes nécéssaires sont déjà installés. 987 987 + L'environnement d'exécution des workflows ne comporte pas d'installation de Gazebo. Étant donné le temps de compilation élevé, on peut "factoriser" cette étape dans une _image de base_, de laquelle on démarre pour chaque exécution du workflow, dans laquelle tout les programmes nécéssaires sont déjà installés. 988 988 989 989 Pour cela, on part d'une image Ubuntu, dans lequelle on installe le nécéssaire: Just (pour lancer des commandes, un sorte de Makefile mais plus moderne @just), FFMpeg (pour l'encodage H.264 servant à la création du fichier vidéo), XVFB (pour émuler un serveur X, cf @simulate-x), Python (pour lancer la politique RL), et Gazebo. 990 990 ··· 1054 1054 [ 1055 1055 1056 1056 ==== Un environnement de développement contraignant 1057 1057 - Développer et débugger une définition de workflow peut s'avérer complexe et particulièrement chronophage: n'ayant pas d'accès interactif au serveur éxécutant celui-ci, il faut envoyer ses changements au dépôt git, attendre que le workflow s'éxécute entièrement, et regardé si quelque chose s'est mal passé. 1057 1057 + Développer et débugger une définition de workflow peut s'avérer complexe et particulièrement chronophage: n'ayant pas d'accès interactif au serveur exécutant celui-ci, il faut envoyer ses changements au dépôt git, attendre que le workflow s'exécute entièrement, et regardé si quelque chose s'est mal passé. 1058 1058 1059 1059 Par exemple, si jamais des fichiers sont manquants, ou ne sont pas au chemin attendu, il faut modifier le workflow pour y rajouter des instruction listant le contenu d'un répertoire (en utilisant `ls` ou `tree`, par exemple), lancer le workflow à nouveau et regarder les logs. 1060 1060 1061 1061 - Ceci rend le développement assez fastidieux, surtout quand le workflow s'éxécute pendant des dizaines de minutes. 1061 1061 + Ceci rend le développement assez fastidieux, surtout quand le workflow s'exécute pendant des dizaines de minutes. 1062 1062 1063 1063 ==== Émuler un serveur graphique <simulate-x> 1064 1064

+28 -26

rapport/nix.typ

reviewed

··· 4 4 5 5 === État dans le domaine de la programmation 6 6 7 7 - 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. 7 7 + 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 (argument) de la fonction en question @purefunctions. 8 8 9 9 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. 10 10 ··· 23 23 return date.today().year + a 24 24 ``` 25 25 26 26 - Selon l'année dans laquelle nous sommes, $mono(f)(0)$ n'a pas la même valeur. 26 26 + Selon l'année dans laquelle nous sommes, `f(0)` n'a pas la même valeur. 27 27 28 28 - 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. 28 28 + De manière donc très concrète, si cette fonction `f` fait partie d'un protocole expérimental, l'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. 29 29 30 30 === Contenir les effets de bords 31 31 32 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 32 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?]. 33 33 34 34 - 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 34 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. 35 35 36 36 37 37 === État dans le domaine de la robotique ··· 43 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. 44 44 45 45 46 46 - === Environnements de développement 46 46 + === Reproductibilité de la compilation 47 47 48 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) 48 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++#footnote[Il est ici question de CMake, qui génère des Makefile configurant GCC] @cmake) 49 49 50 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. 51 51 ··· 53 53 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) 54 54 $ 55 55 56 56 - 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. 56 56 + Ici, $P_1$ et $P_2$ sont deux itérations du code source (éléments de 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. 57 57 58 58 - 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 58 58 + On a la proposition (1), avec $E = "src"$, l'ensemble des code source possibles pour un langage, et $F= "bin"$, l'ensemble des binaires exécutables 59 59 60 60 Nix ne peut pas garantir que le programme sera sans effets de bords au _runtime_, mais vise à le garantir au _build-time_. 61 61 ··· 63 63 64 64 === Un _DSL_#footnote[Domain-Specific Language] fonctionnel 65 65 66 66 - 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 66 66 + Une autre caractéristique que l'on trouve souvent dans la famille de langages fonctionnels est l'omniprésence des _expressions_: la quasi-totalité des constructions syntaxiques forment des expressions valides, et peuvent donc servir de valeur 67 67 + 68 68 + #todo[améliorer exemple, ya des ternaires dans tt les langages...] 67 69 68 70 #table( 69 71 columns: (50%, 50%), ··· 101 103 ```, 102 104 ) 103 105 104 104 - Voici un exemple de définition d'un programme, appelée _dérivation_ dans le jargon de Nix: 106 106 + Voici un exemple de définition d'un paquet Nix, appelée _dérivation_ dans le jargon du langage: 105 107 106 108 107 109 ```nix ··· 146 148 } 147 149 ``` 148 150 149 149 - 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) 151 151 + La dérivation prend ici 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 du programme, qu'elles servent à la compilation ou à son exécution (dans ce dernier cas de figure, les dépendances sont inclues ou dynamiquement liées dans le binaire final) 150 152 151 153 === Un ecosystème de dépendances 152 154 153 153 - 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. 155 155 + 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 paquets Nix, disponibles sur un registre centralisé, _Nixpkgs_ @nixpkgs. 154 156 155 155 - 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 157 157 + Ainsi, écrire un paquet Nix pour son logiciel demande parfois d'écrire des paquets Nix pour les dépendances de notre projet, si celles-ci n'existent pas encore, et cela récursivement. On peut ensuite soumettre ces autres paquets à Nixpkgs @nixpkgs-contributing afin que d'autres puissent en dépendre sans les réécrire. 156 158 157 157 - 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 159 159 + Pour ne pas avoir à compiler toutes les dépendances soi-même quand on dépend de paquets sur _Nixpkgs_, il existe un serveur de cache, qui propose des binaires des dépendances, Cachix @cachix 158 160 159 161 === Une compilation dans un environnement fixé 160 162 161 161 - 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é. 163 163 + 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) pendant la compilation#footnote[La date système n'est pas modifiée par Nix, mais il expose une date zéro au processus compilant le logiciel]: le programme compilé ne peut pas dépendre de la date à laquelle il a été compilé. 162 164 163 163 - 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 165 165 + 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 164 166 165 165 - ==== Un complément utile: compiler en CI 167 167 + ==== Un complément utile: compiler en _CI_ 166 168 167 167 - 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. 169 169 + 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 compiler 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. 168 170 169 171 == NixOS, un système d'exploitation à configuration déclarative 170 172 171 171 - 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. 173 173 + Une fois le programme compilé avec ses dépendances, il est prêt à être transféré à l'ordinateur ou la carte de contrôle embarquée sur le robot. 172 174 173 175 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. 174 176 175 175 - 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,… 177 177 + 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, etc. 176 178 177 177 - 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. 179 179 + Sur les distributions 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'exécution de commandes. 178 180 179 179 - 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. 181 181 + C'est un problème assez récurrent avec 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. 180 182 181 181 - 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. 183 183 + Ici, NixOS assure que toute modification de l'état du 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. 182 184 183 185 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. 184 186 185 187 == Packaging Nix pour _gz-unitree_ 186 188 187 187 - Le packaging pour Nix de gz-unitree lui-même n'est pas très complexe: il s'agit d'un projet C++ / CMake standard. 189 189 + Le packaging pour Nix de _gz-unitree_ lui-même n'est pas très complexe: il s'agit d'un projet C++ / CMake standard. 188 190 189 189 - Cependant, gz-unitree a deux principales dépendances 191 191 + Cependant, _gz-unitree_ a deux principales dépendances 190 192 191 193 - Gazebo lui-même, à travers `gz-sim`, `gz-sensors`, `gz-common`, `gz-plugin`, `gz-cmake`, etc. 192 194 - Le SDK2 d'Unitree

+10 -1

rapport/sdk2-study.typ

reviewed

··· 2 2 3 3 #show figure: set block(spacing: 3em) 4 4 5 5 - Unitree met à disposition du public un _SDK_#footnote[Kit de développement logiciel (Software Development Kit)] permettant de contrôler ses robots (dont le H1v2). 5 5 + == Le robot _H1v2_ d'Unitree 6 6 + 7 7 + Le _H1v2_ est un modèle de robot humanoïde créé par la société Unitree. 8 8 + 9 9 + Il possède plus de 26 degrés de liberté, dont 10 10 + 11 11 + - 6 dans chaque jambe (3 à la hanche, 2 au talon et un au genou), 12 12 + - 7 dans chaque bras (3 à l'épaule, 3 au poignet et un au coude) @h1v2 13 13 + 14 14 + Unitree met à disposition du public un _SDK_#footnote[Kit de développement logiciel (Software Development Kit)] permettant de le contrôler. 6 15 7 16 == Canaux DDS 8 17