Architecture logicielle

Le fonctionnement de notre équipe :

Nous avons découpé le développement de notre solution logicielle en jalons courts d’une semaine. A la fin de chaque jalon, notre objectif est d’avoir un nouveau livrable, ce qui nous permet d’apprécier pleinement l’évolution du projet. Cette méthode de développement largement inspirée des méthodes agiles standards fonctionne parfaitement pour notre petite équipe de 6 développeurs.

Description des semaines :

Première semaine :

La première semaine correspond pour nous à la phase de prise en main du projet. Notre première tâche a donc été de réfléchir à une architecture à mettre en place dans le code pour que toutes les phases de développement se passent le plus facilement et rapidement possible. C’est une étape cruciale dans le projet car c’est là dessus que tout le code que nous allons produire par la suite se base. De plus, rectifier l’architecture alors qu’une partie du code est déjà écrite est une tâche assez délicate et qu’on souhaite éviter. Notre approche a donc été assez simple : on ne touche pas au code tant que l’architecture n’est pas finie et approuvée par l’ensemble des développeurs.

L’architecture choisie se base sur le design pattern requirer / provider. De manière simple, pour faire marcher ce type d’architecture on identifie des services ou fonctionnalités que des composants peuvent offrir ou demander.

diagramme_composant
Diagramme de composants

Nous avons choisi de faire correspondre les composants logiciels avec les composants physiques que l’équipe Atelier peut monter sur le robot. Ainsi dans un premier temps, nous avons identifié des composants pour le moteur, qui encapsule tous les appels à la carte moteur et pour le capteur de distance à ultrasons qui nous permet de gérer les deux capteurs avant et arrière montés sur le robot. Il nous sera aisé par la suite de rajouter de nouveaux composants lorsque plus de matériel sera monté sur le robot (gyroscope, compas, bras mécanique…) . En plus de ce premier composant, nous avons choisi d’intégrer toute la logique qui fera fonctionner le robot dans un composant Brain, dans lequel nous développerons tout l’intelligence artificielle.

Le premier livrable a donc été une ébauche de l’architecture en code C++, l’implémentation des composants remplacée par des composants bouchons temporaires.

Deuxième semaine :

Après nous être occupé de poser des fondations stables lors de la première semaine, le développement “réel” a pu commencer cette semaine. Grâce aux quelques expérimentations que nous avions fait le semestre précédent, nous ne partons pas de zéro pour ce qui est du développement sur architecture embarquée. Forts de cette petite expérience, il nous a été assez aisé de reprendre la logique que nous avions développée et de l’intégrer dans notre architecture de composants. Tout a été ensuite une histoire de calibrage pour faire fonctionner le sonar.

A l’issue de cette deuxième semaine, nous avons fourni un comportement très basique pour le robot, qui avance jusqu’à ce qu’il détecte un obstacle devant lui.

Troisième semaine :

Cette semaine, nous avons commencé à vouloir développer un comportement un peu plus complexe, et qui nous sera nécessaire pour toute tâche lors de la compétition. Nous avons travaillé en collaboration avec l’équipe R&D qui se charge de la prise en main de nouveaux composants pour intégrer un gyroscope au robot. Ce gyroscope nous donne une vitesse en degrés par seconde sur trois axes x, y et z, qui correspondent à trois axes sur lesquels un objet peut tourner. Pour l’instant, l’axe nous intéressant est l’axe z qui nous permet de déterminer l’angle duquel le robot tourne lors d’un virage. Grâce à ce capteur il nous sera donc possible de tourner de manière précise (à la précision du gyroscope près), ce qui est crucial pour réussir nos tâches lors de la compétition.

A la fin de cette phase de développement, nous avons intégré du code permettant de récupérer l’input du gyroscope fraîchement installé sur le robot. Grâce à cette nouvelle entrée, nous avons pu adapter le comportement du robot pour obtenir des virages plus précis que précédemment. Néanmoins, le résultat n’est pas parfait, il restera à perfectionner cette partie la semaine prochaine.