3 Moteurs sur la Raspberry Pi 2

Moteur et Hélice

Il est maintenant temps de connecter non pas 1 moteur, mais 3 moteurs à notre plate-forme. En effet, le ROV a besoin d'au moins 3 moteurs pour pouvoir se mouvoir correctement (et on pourrait aussi y ajouter 2 moteurs d'étrave pour les mouvements latéraux). Il est donc important maintenant de tenter la connexion de tous ces éléments, les tests précédents ayant été limités à lever les doutes sur l'utilisation d'un moteur. De plus, il sera nécessaire d'adapter le logiciel pour pouvoir avoir accès au pilotage de ces moteurs via l'interface d'openrov-cockpit.

Nous avons déjà pu faire des tests unitaires sur le fait de piloter 1 moteur brushless via la Raspberry Pi B. Ces tests avaient été réalisés sur une Raspberry Pi B. Étant passé à une version Raspberry Pi 2, le connecteur GPIO disponible est plus grand. Cela ne fait que rajouter des ports GPIO supplémentaires et cela ne devrait donc pas poser de problèmes. D'autant plus qu'un adaptation du logiciel ServoBlaster a été réalisée par son auteur en Octobre 2015 pour une adaptation à la Raspberry Pi 2 et au noyau 4.1 Nous allons donc reprendre le travail réalisé précédemment et l'étendre pour pouvoir commander les 3 moteurs nécessaires à notre ROV.

Connexion à la Raspberry Pi 2

Le connecteur GPIO (General Purpose Input/Output) de la Raspberry Pi 2 est plus long que pour la version précédente. Voici le schéma d'implantation physique:

Connecteur GPIO Raspberry Pi 2

Chaque pin supporte une fonctionnalité particulière (même s'il est possible de changer le rôle logiciellement de certain d'entre eux, ce que fait ServoBlaster), voici le schéma de numérotation de ces pins pour le connecteur GPIO de la Raspberry Pi 2:

Numérotation GPIO Raspberry Pi 2

Pour être sûr d'éviter tout conflit avec la plate-forme GrovePi, j'utilise les pins restant de la Raspberry Pi 2. Grâce à un connecteur HE10 2,54mm de 2x5 points, j'ai pu déporter 10 pins (31 à 40) de la Raspberry pour les utiliser plus facilement. Pour démarrer le service servoblaster avec ces ports, j'ai donc rajouté dans le script /etc/init.d/servoblaster à la variable OPTS la valeur:

OPTS="--p1pins=40,38,36"

Les moteurs sont identifiés de la manière suivante via ServoBlaster:

  • 0 (pin 40): Moteur Babord (Port)
  • 1 (pin 38): Moteur vertical (Vertical)
  • 2 (pin 36): Moteur Tribord (Starboard)

Pour le reste, la configuration est identique, la seule modification apportée au script de test étant pour les valeurs extrêmes qui sont: Min = 75 et Max = 225 (la valeur médiane restant 150). Aucun conflit n'ayant été détecté entre le signal PWM sur ce port et la réception de la centrale inertielle dans openrov-cockpit, il ne nous reste plus qu'à connecter la contrôle du moteur à l'interface graphique.

Une petite adaptation du logiciel openrov-cockpit plus tard, nous voici en capacité de contrôler les moteurs de notre futur ROV via l'interface graphique.

Schéma électrique d'alimentation des moteurs

J'ai utilisé un montage en parallèle pour l'alimentation des moteurs, comme pour l'alimentation des prises de courant dans votre installation électrique à la maison. Pour faciliter le cablâge et éviter d'avoir trop de fils qui courent dans tous les sens, j'ai utilisé un domino électrique avec des fils électriques rigides de section 2,5mm² (un noir et un rouge pour bien identifier la masse et le positif). Vous pouvez voir sur le schéma suivant le montage réalisé.

Alimentation en parallèle des moteurs

Mesure de la tension d'alimentation des moteurs

Un point important, afin de ne pas laisser notre futur ROV au fond de l'eau, est de surveiller la tension d'alimentation des moteurs. Pour réaliser cette tâche, il est possible d'utiliser un capteur de tension. Malheureusement, aucun capteur Grove n'est disponible pour cela. J'ai donc eu recours à un autre capteur, compatible avec la plate-forme: un capteur de tension Phidget. Le matériel nécessaire est le suivant:

Ce capteur de tension est un capteur analogique. Il suffit de le connecter à une des entrées analogiques de la GrovePi pour lire les valeurs brutes du capteur à l'aide d'un petit code comme celui des exemples. Deux problèmes se posent alors: convertir les valeurs lues en tension et filtrer les valeurs retournées pour avoir une valeur plus stable.

Pour résoudre le premier problème, il suffit de prendre une première mesure à vide (sans lecture de tension) pour trouver la valeur retournée pour une différence de tension nulle entre les deux bornes (pour ma part, j'ai une valeur de 554) puis de connecter le capteur à la batterie et de relever la valeur mesurer. Puis à l'aide d'un voltmètre, prendre la tension effective à la batterie pour faire la règle de conversion des données lui en volt.

Le deuxième problème est le bruitage des données lues en entrées (les valeur lues à la sortie du capteurs varient de quelques unités, ce qui fait varier en permanence la valeur de la tension au dixième de volt près). Pour lisser ces valeurs en fonction de l'erreur de lecture, j'ai utilisé un filtre de Kalman. Étant loin d'être un spécialiste du traitement du signal et pour éviter de ré-implémenter cet algorithme, j'ai utilisé un paquetage javascript implémentant celui-ci (kalmanjs). Un bon article publié par l'auteur de cette bibliothèque permet de comprendre rapidement le paramétrage à fournir au filtre.

Ceci fournit ainsi la donnée de tension des batteries dans l'interface de pilotage du ROV et permettra d'anticiper une décharge des batteries alors que le ROV est à 20 ou 30m de profondeur. Il y aura bien sûr toujours le câble pour tirer celui-ci de l'eau, mais savoir quand on aura plus de courant est tout de même important.