this repo has no description
Continue rapport
+33
-16
+33
-16
rapport/gz-unitree.typ
+33
-16
rapport/gz-unitree.typ
···
803
803
804
804
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%.
805
805
806
-
En utilisant le _profiler_ de Gazebo @gzprof, on peut capturer des intervalles de temps et les annoter, pour identifier ce qui ralenti les cycles de simulation:
806
+
#grid(
807
+
columns: 2,
808
+
gutter: 2em,
809
+
[
810
+
En utilisant le _profiler_ de Gazebo @gzprof, on peut capturer des intervalles de temps et les annoter, pour identifier ce qui ralenti les cycles de simulation.
811
+
],
812
+
[
813
+
```cpp
814
+
GZ_PROFILE_BEGIN("Label");
815
+
...
816
+
GZ_PROFILE_END();
817
+
```
807
818
808
-
```cpp
809
-
GZ_PROFILE_BEGIN("Label");
810
-
...
811
-
GZ_PROFILE_END();
812
-
```
819
+
]
820
+
)
813
821
814
-
Crée un segment nommé "Label" dans le diagramme du profiler.
815
-
816
-
On peut créer plusieurs segments en parallèle quand le programme possède plusieurs threads:
817
-
818
-
```cpp
819
-
GZ_PROFILE_THREAD_NAME("Nom du thread");
820
-
```
821
-
822
-
On obtient ce diagramme après l'éxécution du programme
822
+
// On peut créer plusieurs segments en parallèle quand le programme possède plusieurs threads:
823
+
//
824
+
// ```cpp
825
+
// GZ_PROFILE_THREAD_NAME("Nom du thread");
826
+
// ```
823
827
824
828
#figure(
825
829
caption: [Profiling d'une simulation avec _gz-unitree_],
···
844
848
)
845
849
)
846
850
847
-
Quelques mesures ont été tentées pour améliorer le RTF:
851
+
852
+
Plus de la moitié du temps de calcul du plugin provient de l'envoi de l'état du robot sur le canal DDS `rt/lowstate`.
853
+
854
+
Notons également que, même si ce cyle-là a duré 0.267 ms, la durée d'un cycle est assez variable, certains atteignent 0.8 ms.
855
+
856
+
#image("./profiler-two-ticks.png")
857
+
858
+
Quelques mesures ont été tentées pour réduire le temps nécéssaire à l'envoi d'un message DDS:
848
859
849
860
/ Restreindre DDS à `localhost`: Il est possible que DDS envoie les messages en mode "broadcast", c'est-à-dire à
861
+
/ Déplacer dans un autre thread: C'est ce qui a motivé la désynchronisation du thread "LowStateWriter" (cf @send-lowstate)
862
+
/ Ajuster la fréquence d'envoi: Une fois `LowStateWriter` déplacé dans un thread indépendant, on peut ajuster la fréquence d'envoi, le thread étant récurrant#footnote[Créé avec `CreateRecurrentThreadEx`]
850
863
864
+
Ainsi que d'autres optimisations, qui ne sont pas en rapport avec cette phase d'un cycle: par exemple, la 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].
865
+
866
+
867
+
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.
851
868
852
869
== Enregistrement de vidéos <video>
853
870