Etape 2: La boucle de contrôle
La partie pilotage fournit les faits pour nos calculs. La prochaine étape est l’estimation d’où le robot doit être dans un premier temps de la partie contrôlée du script.
Tout d’abord nous devrons choisir un intervalle pour la boucle de contrôle, y compris les mesures de capteur. Plus l’intervalle, le mieux c’est : création d’une rétroaction rapide sur nos estimations par les données des encodeurs. L’intervalle devrait de préférence être environ 0,01 seconde.
Le Dagu Arduino comme pilote mini de RB2 permet un intervalle de rétroaction pour les capteurs de 0.01 sec. Mais il y a quelques choses à considérer. Au premier il y existe plusieurs sources de retard (par exemple la durée d’exécution de la boucle de contrôle lui-même). Deuxièmement pour prendre en compte est la résolution de l’encodeur. En d’autres termes : le temps minimum nécessaire pour générer au moins 1 tick à partir de vitesse (c'est-à-dire la vitesse de décrochage). Pour RB2 0,1 sec est utilisé comme intervalle. Une fréquence de rétroaction plus basse de 10 fois a-t-il ses implications sur la boucle de régulation : elle limite le degré de l’écoute des erreurs et des ajustements. Une trajectoire de 2 mètres aura un bon 6 secondes pour terminer (0,31 m/s). Dans cette période, il y aura seulement inférieure à 60 minutes pour lire les données de l’actionneur et mettre en oeuvre les ajustements calculés.
Pour le bon réglage (je vais venir à celle lors de la description de la boucle de régulation), on devrait au moins avoir quelques centaines des boucles d’évaluation. Vous pouvez regarder l’effet dans la vidéo au début du blog : les corrections sur l’orientation sont parfois un peu brusques. Ayant une fréquence plus élevée de rétroaction permettra de lisse-fr les corrections plus. (Une autre cause est la résolution du codeur : l’erreur minimale qui peut être lu est 1 tick. Donc ce que vous voyez sur la vidéo, est le meilleur que je pouvais sortir de la situation.)
Il est essentiel que les évaluations sont font à une fréquence constante. Les variations dans les intervalles sont désastreuses pour la boucle de contrôle ! Voilà où j’ai été confronté à un autre obstacle. J’ai commencé à utiliser la fonction time.time() de Python, mais découvert, il a créé certains pics bizarres. Même si c’est juste un script en cours d’exécution avec seulement l’intervalle de boucle lui-même. Donc, je suis passé à la fonction time.clock() qui est liée au temps processeur lui-même et exécuté le script sur un Windows, Unix et un système Linux. Halas sans meilleur résultat. Même essayé de filetage. Timer() pour générer une boucle de calendrier dans un thread séparé. Cela fonctionnait très bien, mais fait le script beaucoup trop compliqué (pour moi). Comme vous pouvez le lire dans le script, j’ai fini avec la minuterie à un maximum de forme et sauter les boucles de contrôle lorsque la minuterie est supérieure à la limite. Un peu rugueux et il a ses conséquences sur la précision, mais il fonctionne mieux que d’avoir trop d’écarts dans les circuits de contrôle. Probablement on pourrait produire un meilleur timing/gestion des événements en C/C++, mais pour moi qui me prendrait trop de temps pour découvrir à la lumière de ce que devrait faire le script.
Donc à chaque 0,1 sec les encodeurs sont lues, les différences (erreurs) sur nos estimations sont calculées et une nouvelle estimation est faite. Dans le script la vitesse désirée du bot est calculée et définie comme cible. Des cibles sont plus souvent dénommés « Seuils ». Dans le script, une consigne est la vitesse désirée, multipliée par le temps d’intervalle, donnant à la quantité de tiques à faire dans l’intervalle. En fait, ce n’est pas correct. La vitesse est la vitesse à la fin de l’intervalle. Si l'on veut travailler plus précis, il faut utiliser l’équation: Vt = Vo + a.t ou du moins la vitesse moyenne: (Vt – Vo) / t pour calculer le montant exact des tiques qui devrait être fait dans l’intervalle. (V est synonyme de vitesse en m/s, un = l’accélération et t = le temps d’intervalle).
Prenant en compte toutes les limitations, que j’ai déjà décrit, je l’ai gardé simple. Comme le montre la vidéo, on peut atteindre des résultats raisonnables en tout cas. Ayant une valeur de consigne établie, le bot se déroulera à une certaine vitesse et au début d’un intervalle de nouveau, la valeur de consigne peut être évaluée sur les données de l’encodeur. C’est là où commence la partie contrôlée.
