Structure du programme raspi

[charlesvdv]

Discussion pour la structure du code de RaspberryPi.

On doit gérer différentes parties:

• une classe d'abstraction d'I2C (en cours via [WIP] First design to abstract I2C comm behind a class #4)
• une classe qui gère les capteurs US (en cours via [WIP] First design to abstract I2C comm behind a class #4)
• une classe qui fait l'interface entre la commande et l'arduino moteur
• une classe de Logging
• une classe qui gère l'arduino Cinématique (action spécial faite par le robot genre ramasser des modules lunaires, funny actions, ramasser le balle lunaire??)(ou 2 classes pour le grand robot et le petit robot, peut etre plus facile)
• une classe qui gère le robot avec toutes les abstractions et les stratégies (on verra ca plus tard...)
• une classe qui gére la représentation des objets sur le terrain, la position du robot, ... Ca permettera d'avoir une abstraction sur le fait qu'on soit ou pas d'un coté ou d'un autre, etc
• une classe PathFinder pour calculer son chemin par rapport à la carte et sa position

(les taches sont mises plus ou moins en ordre d'importance)

Qq'un a encore une idée?

[azerupi]

ou 2 classes pour le grand robot et le petit robot, peut etre plus facile

Comme on est sur une machine linux, on peut utiliser une variable d’environnement pour choisir si on est sur le grand ou le petit robot. Alors on peut faire un seul code qui gère tout et en fonction de la Raspberry sur laquelle on l’exécute il changera son comportement. Je ne suis pas 100% sur que le code sera plus propre que si on scinde le programme en deux, mais je pense que c'est une piste à explorer.

une classe qui gère l'arduino Cinématique

Je pense qu'il faut une classe par module. Par exemple, pour le gros robot, il aura un système pour attraper les cylindres, un pour les déposer et les retourner. Il est possible qu'on décide que ce soit trois modules séparés ou un seul module unique (à décider quand on aura une idée plus concrete). Mais pour moi, il faut au moins une classe par Arduino (module) qui crée une abstraction pour l'envoie de commande par I2C. Après, il y à moyen de grouper plusieurs de ces classes qui sont sensés fonctionner ensembles pour créer une abstraction de plus haut niveau par dessus.

Dans un premier temps, je pense qu'on doit se concentrer sur le code qui gère le hardware et éviter de trop réfléchir au code pour l'intelligence. Une fois que le hardware est bien représenté dans le code on pourra déjà tester le robot (si la partie mécanique et électronique suit).

[charlesvdv]

Comme on est sur une machine linux, on peut utiliser une variable d’environnement pour choisir si on est sur le grand ou le petit robot.

J'y avais aussi pensé aussi. A voir en effet 😄

Je pense qu'il faut une classe par module.

Je suis bien d'accord mais certaines actions de la cinématique ne demande pas la raspberry pi. La plus part du temps, la cinématique pensée ne requierera pas la raspberrypi.

je pense qu'on doit se concentrer sur le code qui gère le hardware et éviter de trop réfléchir au code pour l'intelligence.

Ce n'est qu'une piste de rélfexion pour pouvoir démarrer le code raspberry pi plus rapidement comme le projet va avancer très vite maintenant que l'on est tous présents.

[azerupi]

une classe de Logging

J'imagine qu'on utilisera le module de logging standard de python. Probablement pas besoin de classe personnalisée.