Menu
Architecture logicielle
Process
Les taches non essentielles au robot et qui de plus ont des risques de crasher sont dans des programmes différents du programme principal (soundPlayer, videoTreatment, sauvegarde des logs sur le disque). La communication entre le programme principal et les sous programmes se fait par shared memory ou socket (pour les logs).
Le programme principal du robot est quant à lui divisé en sous parties gérée par des threads. Chaque thread effectue des taches périodiques critiques: lecture sur les UARTs, commande des moteurs, taches périodiques.
Classes
Toutes les classes héritent de RobotBase qui définit des fonctions de base pour connaitre le nom de la classe et son niveau de debug.
Les classes qui gèrent des capteurs ou actionneurs dérivent de RobotIoDevice
Le programme principal (src/main/robotMenu/robotMenu.cpp) instancie RobotConfig (configuration du robot et variables globales), RobotMain (qui gère l'initialisation de tous les composants de base) et une série de classes dérivant de Strategy qui sont les systèmes haut niveau de contrôle du robot.
Les stratégies utilisent les API haut niveau Hli et Move pour contrôler le robot sans avoir à se soucier de la manière dont fonctionne les capteurs et actionneurs du robot.
Les classes correpondant aux capteurs et actionneurs peuvent être instanciées de manière réelles ou simulées (interface avec le simulateur).
Un simulateur permet de tester le code embarqué dans le robot rapidement et simplement. Il utilise des classes simulées de MotorSimu, et HliSimu. Il simule les déplacements du robot, les informations des capteurs et les interaction du robot avec son environnement. L'année prochaine il faudrait faire un système détaché du programme principal du robot qui permettrait de faire s'affronter 2 fois le même code du robot.
Il ne faut pas le confondre avec le Viewer3D qui n'est qu'un module permettant de dessiner le terrain en 3D. Celui ci est utilisé par le simulateur et le viewer de logs.