Un petit simulateur

Vous vous souvenez de nos dernières aventures ? Les contrôleurs moteurs généraient trop de bruit pour que les encodeurs soient utilisables. On a donc décidé d’acheter des MD13S pour contrôler les moteurs.
Mais le temps que ceux à qui on les as acheté aille les chercher à la nage les mains dans le dos en Malaisie, impossible de faire le moindre test. C’est embêtant !

Au détours d’une conversation on se dit : “Ah, si on avait un simulateur basique qui nous permettrait de tester l’asservissement et l’odométrie…”
Et sachant qu’on a rien à faire de mieux en attendant, c’est partis !

Qu’est-ce qu’on veut exactement ?
Déjà, quelque chose de simple. Le but est de ne pas passer plus de temps à développer le simulateur que le vrai robot. On met donc de coté pour l’instant une simulation physique tenant compte de la masse du robot.
Ensuite on veut pouvoir tester l’asservissement, mais sans pour autant régler les coefficients du PID. Un robot sans aucune inertie n’est pas réaliste et  ne permettrait pas de bien tester l’asservissement.
On veut se mettre au plus proche du moteur. On va donc remplacer l’appel de la fonction analogWrite et la lecture des encodeurs par l’appel de méthodes du simulateur, qui va simuler les 3 moteurs.
Pour la simulation des moteurs, on va partir sur un 1er ordre, comme on a appris il y a longtemps en prépa !

On veut donc que chacun des moteurs ait un comportement de la forme K1*exp(-t/Tau) + K2.
Mais comment faire ça en temps discret ?

Un parcours rapide d’un cours trouvé sur internet (et oui, je l’ai appris mais j’ai oublié) et on trouve la solution :

x[n+1] = x[n] + x'[n]*dt
x'[n+1] = -x[n] / Tau

Avec “x” la variable qui va suivre un premier ordre et “x'” sa dérivée.

Après un peu de réflexion, on fait un petit test sur un tableur pour voir si ça marche bien :

On a donc :
vp[0] = vInitiale – vFinale
a[0] = 0

puis :
vp[n+1] = vp[n] + a[n]*dt
a[n+1] = -vp[n] / Tau
v[n] = vp[n] + vFinale

Plus qu’à implémenter ça sur le robot !

Et voilà le travail !
En bleu c’est la consigne de vitesse que le moteur doit suivre, et en rouge c’est sa vitesse. Assez réaliste n’est-ce pas ? On pourrait presque régler l’asservissement avec !

Maintenant les pistes d’amélioration :
– Simuler un peu mieux la mécanique en intégrant le diamètre des roues, le rapport de réduction, et pourquoi pas, les coefficients du moteur !
– Simuler l’inertie du robot avec la fameuse loi de newton : masse * accélération = somme des forces.

 

trop d’insouciance

Aujourd’hui, je suis tombé de mon piédestal d’insouciance pour apprendre une grande leçon d’électronique : se méfier des interférences.

Jusqu’à présent, j’avais toujours utilisé une carte dédié au contrôle de moteurs : les MD10C de Cytron.

Cette année je me suis dit que je n’avais pas besoin des 10 ampères en continu promis par ce contrôleur, et qu’ajouter une carte par moteur me prenait trop de place sur le robot.

J’ai donc fait une carte électronique en utilisant des LMD18200 afin de contrôler les moteurs, sans prendre aucune précaution contre les interférences. Bien mal m’en a pris, comme vous le constaterez sur la photo ci dessous : les interférences des moteurs me pourrissent le signal des encodeurs, empêchant tout asservissement correct des moteurs.

J’ai donc maintenant le choix entre refaire une carte intégrant des protections contre les interférences, par exemple avec des optocoupleurs, ou revenir en terrain connu en utilisant des MD10C.